Data security while MacBook is on lock screen

I don't have detailed information on FileVault, but all FDE (Full Disk Encryption) schemes perform best when computer is cold, namely shut down completely.

FileVault suffers the same weaknesses as other FDE schemes such as MS BitLocker and LUKS: while they secret key is stored on RAM an attacker with appropriate tooling may reset the CPU and dump RAM contents before the content vanishes. This is no simple thing to do, especially when hardware is compact enough. But is very well documented as a weakness of FDE.

Please note: data is always stored encrypted on disk. The data is not decrypted after boot. FDE decrypts only the data it needs every time, and decrypts that into RAM. Swapping a spinning disk has no effect with regards to security.

You said tech took 5 minutes to replace the key. I don't have record of how much time it takes to perform the hot boot attack, but data being volatile in RAM is matter of time.

I would be very confident that either:

The tech did just his job to replace the hardware keyboard honestly
In the back of the tech shop there were two techs paid by some government agency: one actually replaced you keyboard, the other was working to spoof national-security secrets (i.e. I am currently responding to a diplomat, a prosecuted national hero, a wanted terrorist or a mafia...) within 5 minutes of your arrival. They knew you were coming to that shop, they broke your keyboard on purpose to have you there, that day, that time. Mr. Bond would be a little surprised.

In short: I am confident your data is safe. Bomb me if I am wrong


HTTP Reverse Proxy: Correct way to do SSL to backend

First, set your CN to be on the FQDN (which is what it should be in the first place), so it doesn't matter what IP address it's on.  Second, you could use internal certs if you wanted to, that's one option, however this needs to be extremely locked down and segmented.

Typically what I'd do for something like that is one of two solutions, depending on what was at my disposal:
 - Use internally-signed certs on the back end, and on the reverse proxy, use 1 cert purchased with the correct number of "units" of servers that it is frontending.  The bonus here is you have separate keys so if one is compromised you aren't compromised the whole way through.  You also have the ability to stagger expiration dates so, if one hits expiration, you can take it out of the group (maintain uptime of the app) while you update all of the certs.  Make sure that the reverse proxy has the latest expiration date.
 - Get an external CA to sign your cert and copy the cert/key from the reverse proxy to the backend servers.  Here you have one key in multiple places, so if it is compromised,  you're compromised the whole way through.  Additionally, if the cert expires, it expires at the same time everywhere, but you still have to update it everywhere when you get a new cert.  This is not always legit, but VerSign didn't mind.  There are also different costs depending on the user of the server (Active/Passive, Primary/DR, Active/Active, etc.) so be sure to discuss with your CA.


Should Longer Random Data Have More or Less Entropy?

I have tested different sizes of data from the Arduino, and found that longer data usually resulted in a noticably greater entropy (7.98 over 7.95).

This is actually most likely due to the fact that randomness tests typically require obscene amounts of input data. Accurately assessing the raw input from a true randomness source can sometimes require terabytes of input! When less input is provided, the tests are less accurate. Think about it from a theoretical perspective: If I give you the bit 1, how certain are you that it is random? What if I give you 11? What about 111? As you see more bits, you can determine with a greater probability that this is not random. I imagine it won't take many more 1s for you to conclude that I am just giving you the same bit over and over. Randomness testing algorithms are similar, though they use more thorough tests than "how often does a single bit repeat", of course. But the same principle applies, and the tests will always require a fairly large input.

  This is strange, as I have heard elsewhere on the internet that /dev/urandom decreases in entropy after the entropy pool is drained.

This is a pervasive myth caused by a very misleading manual page. In reality, /dev/urandom will be able to generate a virtually unlimited amount of pseudorandom data perfectly indistinguishable from "true" randomness as long as it is seeded initially with at least a hundred or so bits of entropy.

  My question is should true random data have more or less entropy when longer? Why?

Technically, a true random source will have as much entropy in bits as there are bits of data. 5000 bits of data can exist in 25000 different states. If that data is true randomness, then all of those states will be possible with equal probability. If you add one more truly random bit (i.e. a bit that has a genuine, true probability of 50% of being a "1"), then you have doubled the possible combinations, giving you instead 25000 × 2 = 25001 possible combinations of bits.

  Are pseudorandom numbers any different? In what way?

In the context of computer security and cryptography, the idea of having more "true" randomness is typically not meaningful. This is due to the fact that algorithms called cryptographically-secure pseudorandom number generators (CSPRNGs) are capable of taking a finite number of bits in the form of a key (or "seed") and expanding them into a virtually unlimited amount of pseudorandom bits. A CSPRNG that can be seeded with 256 bits of entropy is capable of producing up to 2256 distinct pseudorandom streams. Despite being limited to "only" 256 bits, it is impossible to determine what the key is (and thus what the subsequent generated bits will be) without iterating through all 2256 possible keys. Since this is not only impossible with current technology, but also impossible even if we harness the entire energy output of the sun for the rest of its life, there is no reason to ever require more than a very small amount of "true" entropy.

  Is there any more reliable way to measure entropy?

Not really. Randomness tests are strange beasts. They are capable of checking for certain biases and as such can tell you that the data is, with a very high likelihood, not random, but it is completely incapable of telling you that it is random. As such, randomness tests would be better off called non-randomness tests! Unfortunately, even state of the art tests only check for certain types of patterns and distributions. Unless you have an oracle that tells you exactly how many uniformly distributed states a number of bits can exist in, you cannot accurately measure entropy.

So, how should you collect randomness from an external noise source like an ADC? You need to gather a few hundred bits (256 is a safe number) of entropy from your noise source and use it to seed a cryptographically-secure random number generator. There are four common techniques:

Use the first 256 bits directly. If you are absolutely sure that your noise source is a true random number generator (e.g. it uses beam splitting or otherwise takes advantage of quantum uncertainty), then this is sufficient. The benefit is that you get the seed very quickly, but the drawback is that you need to trust your noise source to generate true randomness.
Employ debiasing on a large number of input bits. Debiasing is any post-processing technique that reduces the bias in an input. For example, ADC output may be biased towards 1s, but that does not mean it is unsuitable as an entropy source. Even if each bit has a 60% chance of being a 1, that chance can still be genuinely random. Debiasing can then be used to create a uniformly-distributed output. One of the first techniques is Von Neumann debiasing.
XOR the noise source. When you have a random value A and a known or attacker-controlled value B, you can combine them using the XOR operation. If you do A ⊕ B = C, knowledge of B does not reveal any information about C. This allows you to mix together a large number of mutually-independent sources such that the predictability of the final value is at least as unpredictable as the most unpredictable entropy source. This technique is very fast, but is only useful on already debiased output. If there is any internal structure to the noise source, simply XORing it with itself may not be particularly effective.
Pass it to a secure hash algorithm. This is the technique you mentioned you ended up using. A cryptographic hash can take an input of virtually unlimited size and will output a finite digest. This digest has a uniform distribution of bits, and the output says nothing about the input. If given 4 random samples, you can safely combine them with H(S0 || S1 || S2 || S3). Hash functions do not keep the entire input in their state, so memory is not a limit of how many samples you can hash together. This technique is by far the most effective way to combine multiple noise sources or a single biased noise source into a small, random seed that can be used to generate an unlimited amount of randomness later.


I found this old question, anyway I'll try to answer it.

The answer is yes, but not with the code you put. The RFI (remote file inclusion) is exclusive of PHP, JSP and the uncommon HTML SSI (server side inclusion) as you can see here on its definition: RFI definition.

This code extracted from the link I posted is vulnerable to a JSP RFI.

<%
   String p = request.getParameter("p");
   @include file="<%="includes/" + p +".jsp"%>"
%>

/vulnerable.jsp?p=../../../../var/log/access.log%00 - Unlike PHP, JSP is still affected by Null byte injection, and this param will execute JSP commands found in the web server's access log.


A potential CAPTCHA phishing attack against reCAPTCHA?

It seems that no one is going to answer this question.

According to my experiment, Google uses HTTP referer to limit the usage of reCAPTCHA public. When register a new reCAPTCHA account, Google will ask you to type in the site (domain) where you will use the reCAPTCHA public key. Then when a user visits your website and is sending request to reCAPTCHA to retrieve the CAPTCHA image, his browser will put the domain of the website he is visiting into the HTTP referer field. Then reCAPTCHA will know whether the domain of the website that is using the public key is the same to the domain which owns the public key. If not, reCAPTCHA will issue a warning in the browser.


How secure is switching keys if breaking the key is an intractable problem?

Assuming no other variables and parameters come into play than the ones that you have described, then YES your system is secure if and only if the method of hiding the secret is secure, i.e. it is not vulnerable to any ciphertext-only or chosen-ciphertext attacks. In both of these attack types, the knowledge of the key is not required.

So for example if your method of hiding the secret is ceaser-cipher, the strength of your key will be immaterial.


OSCP certification for junior pen tester position any good?

Unfortunately in UK, most companies want you to have the local ones, CREST and CHECK, and of course SANS. OSCP doesn't sell as much as them and ISC or EC-Council.

My advice for you would be to first start with CEH, then GPEN and with a more experience, you can go for OSCP.

To be honest, OSCP is not an entry-level into the world of PT, I would first suggest you to practice all the Metasploitable, DVWA and those tutorials, get a couple of books like Metasploit: The Penetration Tester's Guide, Advanced Penetration Testing for Highly-Secured Environments: The Ultimate Security Guide and most importantly, motivation, and practice.

Now, having these certifications is a plus, but when you get an interview, at let's say big 4, security boutiques, telcos and the like, the most important is for you to be able to communicate the issues with the client at all levels. The thing is, there is no real way to "learn" that. Apart from that, you need to have solid networking skills, understanding of OS, databases and how everything communicates, basic scripting and the like. A very simple question like:

  Let's suppose you're doing a PT, and in the middle of it, you trigger something, the exchange server crashes, client wants you to continue with the PT and meet the deadline but without touching the exchange server

The best for you would be to get a job as a network admin, (junior pentest opportunities are out there, but extremely hard to find) and most of these...well they won't teach you anything you cannot find on the internet, they will most likely never send you to meet with a client and discuss how you're going to scope a pentest and the approach you will take.

Good luck really! Try maybe working as a security consultant and talking with the guys that do PT and gain experience, it's a lot about self study.


How is a hash's algorithm detected based on the hash?

You cannot, in full generality, infer the hash algorithm from the output. An output is just a sequence of bits, and hash functions that produce n-bit outputs can at least theoretically produce any sequence of n bits of output.

However, some people can make quick inferences (perhaps too quick), by saying that among the "usual" hash functions, only one produces 160-bit outputs, and that is SHA-1. (This notion of "usual" excludes RIPEMD-160, which, while rarer than SHA-1, is still widely used as part of PGP.)

IF, at some point in the future, we find a value x such that SHA-1(x) matches one of these hash values, then we will be pretty sure that SHA-1 was indeed involved, and on input x; any other hypothesis would mean that we have just broken SHA-1's preimage resistance, which is, as far as we know, out of our collective technological reach (unless we get very very lucky). However, until this is done, claiming that "this is SHA-1" is just guesswork.


Block specific packets/sequences of packets to remove disturbing client "feature"

No.  If you drop packets from the middle of a connection, the server will resend those packets until they succeed.  If they don't succeed for a sufficiently long time, the server will assume the entire connection has failed and will close the connection.

The reason your IPTables rule is not matching is that IPTables matches against the entire packet length, whereas your 237 bytes is the length of the data in the TCP packet.  The full packet length is at least 20 bytes longer (may be more, depending on TCP options).

You could proxy the connection and actually remove the message at the application layer, but that'd depend on the protocol in use.


With private keys and public keys which is used for which: encrypt, sign, verify, and decrypt?

Decrypt/verify would be used on a received file; use your private key to decrypt, and the sender's public key to verify their signature.

Sign/encrypt would be used when preparing a file to send to someone else, using your private key to sign and their public key to encrypt it.


If I send a fax from an unsecure endpoint to a secure endpoint, is the data secure?

I wouldn't much care if the line were secure, I'd want the connection to be secure.

Consider the possible ways your data could be intercepted:

If you send from a fax machine at your office, the line could be tapped in the corporate wiring cabinet, or anywhere between the machine and the cabinet.
If you send from home, the line could be tapped at the network interface.
The line could be tapped between the network interface and the CO.
A rogue phone company employee could be listening.
A government could be listening ("lawful intercept").
The same set of taps could be in place between the CO and the receiver.
When the fax rolls off the receiver's machine, if the machine is not in a physically secure location (e.g. a locked office), then a casual snooper might see your info.
If the fax is stored electronically instead of printed directly onto paper, it could be "stolen" from the electronic storage system.

So the answer is no, the data is not secure. You need to be able to establish an encrypted connection to the receiver, and (if it is very sensitive) you want to understand how they will be handling the data once it has been received.


Can you use Google's authenticator app when Google "makes sure that you’re really you"?

Yes, you can do what you are asking. Just open the Google Security settings from here and open the "protect my account" section. From there you can add other phone numbers, configure your android device to allow new account logins and also configure the Google authenticator app.


Can a malicious user do any harm using /dev/kvm?

You could protect /dev/kvm with a group.  Transfer /dev/kvm ownership to the group so that root privileges aren't given.  This link explains how to do it, and here's the direct quote:

The cleanest way is probably to create a group, say kvm, and add the user(s) to that group. Then you will need change /dev/kvm to owned by group kvm.
On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to /etc/udev/rules.d/40-permissions.rules).
KERNEL=="kvm", GROUP="kvm"

To answer your question there is no danger in giving them access to /dev/kvm.  This post explains newer memory management provides protections from swapping out large amounts of memory.


If you're a Python programmer you can use the Scapy interactive packet manipulation program to create your own packets and send them.  You can also use it as a library within your own Python program.

From within the interactive program here's how you can create an IP packet, change the source address, and send it.  Scapy will use any default routes you have setup.

>>> pkt = IP(src="1.2.3.4", dst="5.6.7.8")
>>> pkt.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags=
  frag= 0
  ttl= 64
  proto= ip
  chksum= None
  src= 1.2.3.4
  dst= 5.6.7.8
  \options\
>>> pkt.send()

The fun thing about Scapy is that it creates the all lower layer headers for you if you don't specify them with default values.  So in the above example the Ethernet header is created for you already.  So you probably want to manipulate the TCP layer, so the following code will build upon the above example.

>>> ip_layer = IP(src="1.2.3.4", dst="5.6.7.8")
>>> tcp_layer = TCP()
>>> pkt = ip_layer/tcp_layer
>>> pkt.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags=
  frag= 0
  ttl= 64
  proto= tcp
  chksum= None
  src= 1.2.3.4
  dst= 5.6.7.8
  \options\
###[ TCP ]###
     sport= ftp_data
     dport= http
     seq= 0
     ack= 0
     dataofs= None
     reserved= 0
     flags= S
     window= 8192
     chksum= None
     urgptr= 0
     options= {}

As long as your routes are set up correctly to get to your destination you should be able to send the packet.  Scapy will also be able to capture response and what not too if you needed.  The documentation gives good simple examples, but does kind of lack in more advanced examples.  The API isn't well documented but there is a doxygen version up here.


What kind of bugs can be found by dumb fuzzing a desktop app?

Dumb fuzzing

I'm just starting out to learn about fuzzing and have made a dumb fuzzer that changes several random bytes in a pdf file to random values, opens it and detects if Acrobat Reader has crashed. What types of bugs can I expect to find using such a method?

None. Such "dumb" fuzzing has incredibly limited coverage. I would be extremely surprised if that application actually crashed just because a few bytes in the input randomly changed. This would be the case even if the fuzzer was trying millions of samples per second. However you also say that your fuzzer opens it and sees if it crashes. This would only get what, a few tries a second? A try every few seconds? Not even close to worth it.
The way some professional fuzzers work is spawning a process, pausing its memory state right before it is about to parse the target data (to skip the bootstrapping state), and then resume it. If it doesn't crash within several tens of milliseconds, it reverts it back to the paused state it was in before. This allows fuzzing at hundreds of times per second at the slowest, or tens of thousand at the fastest.

I assume that a format string vulnerability could be found in case the dumb fuzzer happens to inserts a format string parameter at the right place. I also assume that integer overflows could be found. But what else could be found?

This depends on how the parser works. Without having the Acrobat Reader source code, I couldn't even begin to answer this question. Buffer overflows, string format vulnerabilities, integer overflows, logic errors, etc. are all possible. You also have to be aware that not all vulnerabilities will be easy to discover, since some parts of the input may be protected with a checksum, complex magic number, or may be compressed.
Imagine you have a field protected with a simple checksum. The chances that random changes will result in a collision are quite low, since that is what the checksum is designed for, and as a result a vulnerable code path may never be taken. However an actual exploit could simply make sure the checksum is valid. This is a common issue with new users fuzzing the rar format. The entire file is covered with a checksum, so no matter how much naive fuzzing someone does, it will never crash. When the checksum code is removed, it turns out to be quite buggy and easy to crash. To avoid this issue, you have to understand the format and either remove the checksum code, or ensure your input always uses correct checksums.

Is it possible to find buffer overflows? Since I change only few random bytes, I assume that the chance of overflowing a buffer is actually small or none. Or am I wrong?

If you change a value that ends up specifying the size of a buffer, then even if you don't change the size of the buffer, it may still result in an overflow. For example, take a hypothetical memory contents here is some text17. This is composed of a buffer, here is some text, and a size, 17. A permutation that modifies the size so it is lower would result in the buffer overflowing once it is processed. Now it's not likely that Acrobat Reader has something this obvious, but a bug could hypothetically result in a similar outcome internally. I could imagine several possibilities.
Intelligent fuzzing
Professional fuzzers do not just throw random input at a program to see if it crashes. They modify the input in specific ways that are likely to result in changes in target behavior. The program is compiled with special code inserted that causes it to report its internal state to the fuzzer at each branch, allowing the fuzzer to know when a given input resulted in a different codepath being taken, even if its external behavior doesn't change. This is the technique used by AFL, one of the most popular general-purpose fuzzers. It is intelligent enough to create a valid JPEG file out of thin air, simply by examining the state of a JPEG decoder as it is feeding it input.
In order to write a fuzzer that finds real-life bugs, you would need to either use binary instrumentation like AFL with the ability to automatically analyze the format, or write an application-specific format-aware fuzzer (i.e. one that is deeply aware of the specifics of the PDF format, and is able to create permutations on a per-syntax keyword basis rather than a per-byte basis).


Is it possible to get virus/malware by just connecting to an Android phone acting as a WiFi hotspot?

Yes, a WiFi Hotspot is a proxy which has the means to perform many acts including malicious ones. Be it an android phone acting as a WiFi hotspot or a router or any other devices.

  Passive

  Snoops on your traffic, data credentials like passwords etc.

  Active

  Redirect you to malicious links resulting you in downloading malware
  or pushing malware to your device.

There are known trojan that can perform malicious acts via a hotspot and there are countless more unknown (it's a guaranteed).

It is the unknown that we are unsafe from. So the best thing is to connect only to a WiFi hotspot that you know and are familiar with.

Last but not least, do you want to apply the two second rule here? Drop a donut on the ground, pick it up in less than two seconds; ok cool. No bacteria, I can eat it.

In this case, just connecting for that split second and then disconnecting does not mean you're safe. Data similarly can be ex filtrated in that few seconds.

Better safe than sorry, recent years of leaks show just how vulnerable we are in security and privacy.

Some research here

Commercial Surveillance Tools Being Used as Mobile Malware
Xsser mRAT Targets iOS and Android for Man-in-Middle Attacks
Smartphone infections double, hotspots are also a trouble area


Impact of sharing my device MAC to access wifi?

The Media Access Control address is simply used to allow the wireless router to find your device across the radio frequency, and to identify your phone when you want to speak to the router's radio antenna. It is not used, or visible, outside the wireless network, so is not used as part of any secure connections to services outside that network.

Secure services like WhatsApp are not vulnerable to inspection by simply capturing the traffic, as they use end-to-end encryption. Websites and apps that do not use encryption can be inspected by the network operator.

The unique risk versus an open wireless network is that the network operator can now use that MAC address to correlate network traffic with your device. If they notice unwanted traffic, they can see the MAC address participating in that traffic and know that you are the owner/operator and probably responsible for that traffic.


Privilege seperation when using the same login credentials?

If I understand your question, your credentials are not strictly speaking the same. Normally your credentials consist of the identity name (account name) as well as the authentication credentials. It sounds to me that you have two different sets of credentials, but which happen to have the same authentication credentials?

If that is the case and given the limited scope you outline, I would suggest there is no significant risk and would argue it is certainly a big improvement over just adding admin rights to your normal operating account (which seems to be the most common user 'convenient') solution.

It would not be an approach I would normally recommend as I think there are other issues (ruled out in your scope statement). If you think about it, on any large server it is quite likely you will have two accounts which have the same password, but this doesn't reduce the security of either account.

The main danger I would see here is with being logged into the account with admin privileges by accident or without realising it - different authentication tokens is often a convenient safety net to ensure you are logged into the account you meant to - finger memory and automated processes when in a hurry can have interesting side effects - probably not an issue if your authentication is managed by smart card, in which case, this is probably a nice compromise compared to having to carry two smart cards!


Use my own wordlist for single mode in John the Ripper

First, (unless you're talking about "single crack" mode generally), I'm not sure what you mean by "a reduced wordlist of user information". It sounds like you may be describing a simple wordlist attack, which is executed with the --wordlist [wordlist] option.

Second, from the JtR modes documentation, the wordlist used by "single crack" mode is:

  It will use the login names, "GECOS" / "Full Name" fields, and users'
  home directory names as candidate passwords, also with a large set of
  mangling rules applied.

The way to run a "single crack" attack on a separate system is to simply supply the entire /etc/shadow entry to JtR as the target "hash". (In other words, it's not pulling the data from /etc/shadow directly; instead, you are extracting that information and supplying it separately.) When run in "single crack" mode, it knows how to parse each field and use them accordingly.


PCI Compliance requirement when storing card data on user's device

PCI-DSS rules generally require that any PAN stored be encrypted in such a way that it requires not one, but two authenticators to decrypt.

In practice, this would normally mean that even if you intend that the end-user is the only one with an encrypted copy, this would be insufficient from a regulatory standpoint. "Who" has a copy is irrelevant, in this respect. If decryption can be accomplished by a single key from the provider (i.e., you), and you cannot affirm that the device it's stored on is encrypted (that is, a client responding with a true/false about the filesystem encryption following a transaction request is not currently a capability of any mobile device I'm aware of), then you will have no way to declare the end-user devices out-of-scope during a PCI audit.

One scenario might work: if you have an application which generates and secures its own key for storing the card information, and which then can respond to your server-side payment application with a token for previously-used cards at that site, then you can (probably) satisfy the basic requirements. As long as the server-side application can satisfactorily store and retrieve the PAN upon presentment of a reference token during the transaction, you're fine. However, even in that case the CVC or CVV must be manually provided by the user— that is explicitly not allowed to be stored together with the PAN.

Having the end user store their own card may also possible, but no program or application can be allowed to request that data from the end-user and expect to receive the response automatically, unless you store a unique key for that user server-side for decryption of the PAN. This is why the current strategy is for Android and Apple to store "card details" and autofill fields when they recognize a request to fill out transaction data. That should be fine, but a pedantic auditor could easily demand that you have some way of confirming the end-user's device only works with an encrypted filesystem.

Long story short: you effectively just want a page whereby someone's mobile browser can work with "autofill" in a friendly way. You'll get the same results, without having to worry about additional PCI PAN storage limitations.


Is this way of using Authorize.net's CIM PCI compliant?

If you're transmitting credit card information through a non-SSL connection to your servers, you're not PCI-DSS compliant.  It is a requirement all personally identifiable information is transmitted through secure (encrypted) connections.

Regarding the rest - the storing of unencrypted information: expiry date, etc - the answer depends on your company's classification under the PCI-DSS rules; if a small company, there are less stringent requirements.

I recommend reading the PCI-DSS documentation thoroughly before proceeding with this. It can be found here: https://www.pcisecuritystandards.org/security_standards/documents.php

Note: once you think you're compliant, you should have a compliance test run by an external auditing company (I use SecurityMetrics but they're not the most fun company to deal with). They are then usually done quarterly to ensure continued compliance.


How do IP addresses leak information about whether they are a home client or not?

How does your IP address leak this information?

It doesn't.
IP addresses are not random things but different companies own different parts of the address range. Thus the usage of specific IP address does not change a lot, which also includes the range of IP addresses used for end users in DSL, cable or mobile networks or the IP addresses of VPN exits or public proxies.

There are several public services you can use to query the status of a specific IP. See for instance Dial-Up/Cable/ADSL IP Addresses at dns-rbl.com. Similar lists exist for known public proxies, VPN endpoints, Tor exit nodes...

  Even if one can do this effectively, is it a good thing to do?

It is heavily used in fighting spam, i.e. end users are often denied to send mail to the mail servers of a specific domain directly, but must instead use the mail server of the mail provider with authentication. Since lots of spam traditionally was sent from botnets consisting of owned end user PC this blocking effectively reduced spam and thus is a good thing.

The same is with public proxies , VPN or Tor. While they have their use in providing (limited) anonymity for honest users they are often misused to circumvent access restrictions or to let an attacker or troll hide its identity when harming other users or companies. Preventing this misuse is in the interest of most and blacklisting these IP is a useful way, even though there is collateral damage against the honest users.


How do I securely separate a wireless subnet from the wired network?

I hesitated a bit to offer up Rodney's answer as I'm not sure that many consumer based ISP gateways have this level of granularity in the setup.  Also a firmware change, hardware change, ISP change basically renders your network inoperable until you reconfigure that new ISP device (if it even has the same options).

Rodney is talking about basically trying to slice the pie, lets say your "cable router" has the lan site network configured like 192.168.1.0/255.255.0.0.  The device itself has an address of 192.168.1.1.  It has a DHCP server daemon that will hand out IPs in the range of 192.168.1.100-192.168.1.150.  So that is your wired interface.

You can then setup your "wireless router" with an address of 192.168.2.1, just like a static host on your network.  It will use the "cable router" IP as it's gateway.  Then you can setup your wireless firewall to block traffic from 192.168.1.100-150.  Depending on how the Network Processors are architect-ed, it could possibly bog down your wireless router and devices if it has to process a bunch of rules.  Anyway it would hand out a small subnet of addresses maybe the private side is like 172.16.100.1/255.255.255.0  is the gateway and you are handing out 172.16.100.10-172.16.100.20.

It could all be moot and possibly your "cable router" will let you setup VLANs (virtual lans, with virtual gateways) May be called Zones or some other name that infers network segregation.  All in all I would get a SMB sized Router from Ebay.


Secure socket communication between iOS device and 3rd party server

You could generate a certificate on first run and then use certificate/public key pinning within the app to verify that it is connecting to the right server.

This will enable you to use HTTPS over SSL/TLS. Apparently lots of existing apps use self-signed certificates. You could perhaps display the details of the certificate it receives of the first connection to allow the user to verify it is the one just created on their WebSocket server - once accepted, the public key is stored in the app and only certificates with the stored public key will be accepted.


How do I create a detached plain text signature?

The command you want is:

gpg --detach-sig --armor file

This will create a detached signature and will armor it, i.e. encode it with ASCII.

See the GnuPG documentation for more information.


whether the next packet of communication will be sent over the same connection or not

Nearly but not exactly. There is not "packet" at this level of communication, just a data stream. HTTP-Keep-alive will allow multiple HTTP requests over the same TCP/TLS connection instead of only one by not closing the connection immediately after the HTTP response but instead keeping it open for more requests.

  HTTP Keep-Alive header dictates

No, it dictates nothing. By adding Connection: keep-alive to the query (or implicitly by using HTTP/1.1 instead of HTTP/1.0) the client is asking the server politely to not close the TCP connection after the response is done. The server might agree or it might not.

  any client-server communication will take place over the same connection

Not necessarily. There might be multiple TCP/TLS connections open in parallel between browser and server.

  any client-server communication after 60 seconds of inactivity will reinitiate the SSL handshake and then proceed with requests and repsonses.

Client and server can decide to close the idle connection (i.e. no outstanding response) at any time and both have their independent settings and timers. If the connection is closed and the client wants to make a new request it needs to create a new TCP connection and for HTTPS it needs either to resume an existing SSL session on top of this TCP connection or to do a full TLS handshake for a new SSL session.

  Also, how is this connected to a user's session inactivity timeout?

This is completely unrelated. User sessions are managed at the application level. HTTP keep alive is managed at the HTTP protocol level. You can have multiple user sessions within a single TCP connection (with multiple HTTP requests) and you can also have a user session be kept over multiple TCP connections (both after each other and also parallel connections).

  What is the security risk of enabling persistent connection (HTTP Keep-Alive)?

There is none.


So your SSID was reset to its default name, and you're asking if a Malware could be responsible.

Yes, it is possible. Searching on the web if your Router model is vulnerable will help you. Most of the makers patch those kinds of flaw by Making some new firmware version. Keeping the router firmware up to date is a good habit.

Not in the question scope

If this WIFI Router is your ISP property, please call them. They may have scheduled a global factory reset for some reason. (Which is pretty rare)

Make sure you do not use WEP encryption. Exploiting a weak encryption scheme is one of the most popular ways for hijacking a WIFI network.

If you cannot figure out why your Wifi Router has been reset to its default configuration, it might have been compromised.


I can see two reasons, both only half related to security:

The owner of the blog does not have the right to use the images, and does not want the owner of the images to find out that they are being used by image googling them. I assume Google will not pick up upside down matches. (There could also be other reasons not to want to have your images easily reverse googled.)
The owner of the blog wants to prevent people from hotlinking the images. While not impossible, it makes it tricky to link to them (especially on e.g. a forum where you can not set CSS) if you only get them upside down. If nothing else, it is quite a fun prank...


Short answer: No.
Long answer: Nooooooo.

Longer answer: RFIDs typical work via magnetic coupling to both power and to transmit data. By modulating the load on the secondary coil of the magnetic couple (aka transformer), the RFID card is able to effect a back EMF on the primary coil.

RFID-proof wallets disrupt this by creating a Faraday cage (i.e. opaque box to RF) which prevents the magnetic coupling from occurring.

In order words, it is literally a tinfoil hat.

Seriously. You can build your own RFID-proof wallet by putting tinfoil in it.


Is mixing password hash and salt in the same database field more secure?

Having the salt and the password together is pretty common, bcrypt uses something similar. The hash returned by bcrypt has the following format

$prefix$cost$salt+hash

About the scrambling, while it may give you some kind of protection against most attackers, it's just adding security through obscurity. As far as the attacker doesn't know how are you scrambling the result it will give some protection, but once the attacker knows that it won't give any protection

In general, security through obscurity is not recommended as the only security layer, but in this case it's an additional one over good password hashing practices (I'm assuming you use bcrypt or some equivalently secure password hashing algorithm). But IMO, a better security improvement can be obtained increasing the cost/iterations of the hashing function used


Using client certificates for website authentication

A simple Google search on "django client certificate" reveals this, and this, and this, which all answer to your question as: yes, Django can work with certificate-based client authentication.

People don't do that often in practice, because client certificates work only if you can arrange for clients to have certificates, basically meaning that you must manage your own PKI. Software for running your own PKI is available (e.g. EJBCA), but PKI management requires strict adherence to clearly defined procedures, which will take you time; the long-term cost of a custom PKI is very often underestimated (that is, if you want to do it properly).

Client certificates will also inconvenience users, because they won't easily (or at all) transfer their certificates to their tablet or smartphone or even alternate laptop, the way they do with passwords. None of this is really blocking, but it explains the rarity of client certificate deployment.


Running shred on a file in memory is pointless. The data from the file is also likely to be present in application memory, in caches, etc. Memory that belonged to a process it not wiped when the process dies: Linux, like most kernels, wipes memory before granting it to a process, not on release, because that's faster.

Of course, there's no guarantee that the file can be recovered. But there's no guarantee that it can't, either. If your attacker model is that the attacker can see your RAM content, there's a lot you need to take care of. At the very least you need to wipe RAM pages as soon as they're released by the process. You can apply the Grsecurity patches to the Linux kernel, at least the PAX_MEMORY_SANITIZE option. And you need to be careful about what processes are running and might store confidential information. And keep in mind that the kernel stores confidential information too, such as the RNG state and disk encryption keys. The TRESOR patch to the Linux kernel protects the disk encryption keys during normal operation, but it isn't a perfect defense and I don't know of a similar patch for the RNG state.


Gmail sign-in with 2 step verification secure enough for money-generating YouTube channel

Depending on what you mean by "secure enough" 2-Step Verification can help keep bad guys out of your account, even if they have your password.

If you are super concerned about your account,  you may also choose to implement the security key based authentication which can be inserted into your computer’s USB port to authorize logins into your account. This is similar to a code being sent to or generated by your mobile phone, however with physical security keys, you will need to insert it into your device's USB.


3DES is used as symmetric or asymmetric encryption?

3DES is symmetric encryption, always. This means that the same key is used for encryption and decryption and that thus both sender and recipient need to know this key. But it might be used together with asymmetric encryption.

Asymmetric encryption is often used to share the common key then used for the symmetric encryption in a secure way. A typical example is PGP, where (simplified) a random key gets generated, this key gets encrypted with the public key of the recipient (asymmetric) and then the message gets encrypted with the generated key (symmetric). The recipient then can extract the symmetric key using its private key and then decrypt the message using this symmetric key.


Is encrypting whole drive with a randomly generated key better than erasing?

What is it you want to protect against?
 First off you got the problem of not having direct access to the hardware of the storage device (unless you use specialized techniques / software), so there is in fact no way to know if your influencing the same piece of storage, or a new piece of storage.

Secondly depending on what your goal is there can be better solutions than encryption (which is by no means faster than deletion I might add).

if the goal is to prevent data theft / recovery, you are better off physically destroying the discs involved. A few good whacks with a sledgehammer should do the trick, than to be sure you can burn the leftovers. (IC's generally are poor at retaining data at temperatures in execs of 200 Deg Centigrade. and most ferro-magnetic substances also lose magnetic cohesion at those temperatures)
If the goal is to resell / give away / or otherwise re-purpose the device. A good format should suffice. if your unsure about the results do a low-level format. Slow but that does at least clear all data from the disk.
If your goal is to keep the data from a government agency, best to use an industrial degausser on a magnetic disc and a High Voltage on the Print for a Solid state disc. this should remove enough of the data to be completely useless to anyone, bear in mind to remove your tin-foil hat before attempting this and consult with a doctor before buying anything like this as there are risks involved.

I would suggest you first go back to the "why" question, as in "Why do you want to combine quick and secure, 2 mutually exclusive actions when regarding any form of storage. your either quick (as in fast), or secure( as in certain of a specific state / certain that no none but  you can access the data).


SMS OTP as 2FA - should there be sms session id in sms for user's verification?

My guess would be that they're trying to prevent you from entering your OTP on a phishing page. If that's the case, their solution is wholly ineffective.

If you're on a phishing page and you receive a valid OTP, that must mean that the phisher has already entered your username and password to trigger the 2FA. They can simply take the "session id" that's sent to them and forward it on to you, and you'll be none the wiser.

4 digits is also rather short for an OTP. 6 digits is common, 7 or 8 is better. Without proper throttling or account locking 4 digits is trivial to brute force. Even if they throttle it to 1 attempt every 5 seconds it'll take under 10 hours to have a 50% chance of guessing a correct code (of course you'll hopefully notice your phone blowing up with a large number of OTPs during this time and change your password, but still...). And that's not even considering the fact that SMS isn't a secure channel.


Authorization flow: the client requests an authorization code to the authorization endpoint (/authorize). This code can be used againt
  the token endpoint (/token) to request an ID token (in JWT format), an
  access token or a refresh token.

  Implicit flow: the client requests tokens directly from the authorization endpoint (/authorize). The tokens are specified in the
  request. If an ID token is requested, is is returned in JWT format.

  Hybrid flow: the client requests both an authorization code and certain tokens from the authorization endpoint (/authorize). If an ID
  token is requested, it is returned in JWT format. If an ID token is
  not requested at this step, it may later by requested directly from
  the token endpoint (/token).

Source: Sebastián E. Peyrott, Auth0 Inc.  The JWT Handbook (Kindle Locations 262-269). Kindle Edition.


My email is listed as recovery email for an unknown Google account

The devils are in the details.

This message is yet another variant of malicious spoof spam mail tries to trick you to click the link that says "click here to disconnect".

If you hover over the URL, you will see the actual URL are NOT from Google, but some unknown site or shorten URL that will trigger a screen that downloads a malware(AKA Computer virus) or phishing site to trick you to enter Google username and password.

(UPDATE)
there is another possibility mentioned here. Somebody accidentally enters your email address as recovery email (either due to typo or other reasons)
It is mentioned here in google product forum.  If you read through the message, you will notice most people will ask you DON'T CLICK any HTML link from an email.

If somebody wrongly enters their recovery email address, their Gmail account will not be activated. So you don't need to do anything with it.

That email actually is a terrible google email registration process that shouldn't be crafted in the first place. It just gives spammer ways to phish users: pour in tons of similar spam, people will think clicking the link will "fix" the spamming problem.

Perhaps this kind of email should be marked as "SPAM" to warn Google mail developer.


How can I securely generate secret-sharing/multisig keys on a p2p network?

If buyer, seller, and arbitrator are all using the same client and are all "peers", where peers are potentially untrusted and might use a malicious client, there is no one person to trust.

Also, the premise of having one client generate 3 keys and distributing them to others, and then deleting them is a weak premise. The client need only find one way of not deleting an item and this premise falls.

Another option might be to just encrypt something for each of the other 2 using public keys.


Digital signatures and weak hash functions

B) is in fact the correct answer, at least for the kinds of attack found against MD5 and SHA1. Those hashes are vulnerable to a collision attack, which means an attacker can reasonably find two things that hash to the same value. If he gets the victim to sign one, he can then just use that same signature on the other. However, he can't necessarily find another plaintext that hashes to the same thing as a given plaintext -- he must control both plaintexts to exploit this, meaning it doesn't let him attack a signature made before the attack was discovered. The "newer documents" are newer than the attack, meaning they might not be legitimately signed.

Note - this only works if you can still trust the timestamp; if the only indicator of time of signature is in the signed document itself, it could be a fake timestamp.  But as a signer, you don't need to worry about old signatures, just newer ones (so transition to a better hash in the future, but don't worry so much about the past).


Your CDN or you could initiate the revocation. The CDN can request the revocation most likely through the account they have with the CA and from being the "owner" of that specific order.

You can request a revocation still, even though you are not the owner or purchaser of that specific certificate. The CA will request you to prove you are the owner of that domain. If you can prove to the CA that youre the owner of the domain, they will revoke the certificate.

You ultimately are the party granting or denying the use of a certificate for your domain. You can authorize another party to buy certificates on your behalf. And you can revoke that authorization at any time as well.

Each CA has a their own revocation policies and its worth checking out those documents. But the CA/B forum which sets rules and standards for CA's, does state who is allowed to request a revocation. See section 4.9 of the Baseline requirements.

  4.9.2. Who Can Request Revocation
  The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties,
  Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the
  issuing CA of reasonable cause to revoke the certificate.

CA's are allowed to process requests from "relying parties" who can provide reasonable evidence that the certificate should be revoked. In the scenario presented in the OP, you would be the relying party and your CDN would be the subscriber.

Relying parties are defined as:

  Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software
  Supplier is not considered a Relying Party when software distributed by such Supplier merely displays
  information relating to a Certificate.


Security camera NVR is making my network not PCI compliant. What can I do?

PCI compliance is for payment processing. Don't put your cameras on your payment processing system.
You want the cameras on their own network so that any camera system compromise doesn’t become a stepping stone into your financial transactions.
You should of course secure the cameras as well, but they need not have any interaction with PCI once they are isolated.


There's no way to sugar-coat this one. A malware/keylogger installed on your computer means that your passwords are exposed. That's it, there's no way around it.

A malware/keylogger will log your master password, intercept the clipboard, somehow access the decrypted database in memory, etc.


Certificate Policies & Certificate Practice Statements - Destroying Vs. Archiving CA's Private Keys (HSMs)

My gut feeling on this would be whether or not there should be recoverable access to archived, encrypted traffic or not.

Policy #1 (Destroying all copies of the private key) from Cisco is attempting to:

Prevent the old certificate / private key being stolen and used for some kind of spoofing / nefarious activity (even after expiration some things can be done)
Prevent an attacker from being able to gather a large amount of encrypted traffic over a period of time, then steal the archived private key at some point and decrypt old traffic

I'm not sure what benefit policy #2 would give besides allowing you to recover raw encrypted traffic at some later point if you needed to, after you've rotated the certs out.


How to detect if a system admin reads CEO mail from outlook server?

Not reliably.
Your main problem is that the admin probably needs to access those files for legitimate reasons, and it's very hard to separate him doing routine maintenance from him actually reading the content.
If he were to read/export them through the online interface it would obviously show up in the audit logs, but for the sysadmin there are a lot of ways to read the files, and you can't reliably detect all of them.
But to set up detection where you can, you could try a combination of these:

Monitoring local file/folder access
Writing an IDS signature to detect network exfiltration

Monitoring local access will catch more than an IDS, but it will contain lots and lots of routine access.
For the IDS rule you'll want to detect for a unique string found in his PST file like a GUID


Is there such thing as an OS "internal firewall"

But it is only about making channels unidirectional. It suggests that security for bidirectional channels has already been solved, but I cannot find more information.

It suggests that a bi-directional channel is simply a pair of uni-directional channels.

By the way, they hardly "solve" the problem of uni-directional channels, due to the "back channels" described. Sure, the bandwidth of a back channel is low. But how much bandwidth do you need to steal critical data like an encryption key, passphrase or a private key? Answer: 128 bits for either of the first two, 2888 bits for an SSH-format ECDSA private key. Even if you can only transfer one bit per second (a very pessimal estimate), 2888 bits is less than an hour.


Tools needed to setup a paranoid remote backup server

You need just the most recent copy of the data, or a historic backup, like version control?

supposing you have two computers running linux (easier) or even any other OS that have the needed tools implemented and you want only the latest backup:

install SSH and create a tunnel between the two computers. You can choose to use the strongest key you need
configure firewall to only accept communications between the two computers
configure Rsync to make the backup between the servers, in the needed frequency (ex.: daily backup running every night)
the destination computer (remote one) could have disk encrypted. And he could get the keys from the source server.

And be sure that physical access is limited on the destination server.

This way:

at a specific time, the backup server mounts the encrypted disks asking for the key that is in the source server
after some minutes the rsync begins to update the files in the dest drive
when it's finished, you have the files in the recent state.
umount the drive, and you're done.

Rsync is good because it only copies what is different between the files, so it's very fast to do backups with it.

It's possible to use rsync to make incremental backups too: take a look at this site


Can one factor be used multiple times in multi factor authentication?

Note that MFA includes both 2FA and 3FA.

The widely accepted definition of multi-factor authentication (see this NIST definition) is:

  Authentication using two or more different factors to achieve authentication. Factors include: (i) something you know (e.g., password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).

Emphasis on factors, not pieces of information.

Therefore, your proposed scheme would qualify as 2FA, which is a form of MFA ("two or more different factors"), but not 3FA.

True three-factor authentication involves a password/PIN + a token/smart card + a biometric characteristic.


How to secure CC details and CCV for a small hotel?

How can we safely store credit card details including CCV until the client has stayed in the hotel and then delete them? Is it even legal?

It is not. You cannot purposefully store this information, allowed storage is the few seconds needed for the hotel to forward it to the bank to check its validity.
If he stores the CVV in any way which would let him send it without the cardholder entering it, then that is a violation. Him writing it down as 'insurance' is a violation.

CVV numbers are not needed to process the transaction, they are just another layer of protection against fraud. The hotel owner may only use it to verify the owner of the card. If the hotel owner uses the CVV number in the charge it denies the card owner the ability to successfully charge back an unauthorized transaction since the Credit Card company will deny the chargeback.

What would make his life easier is getting a downpayment that people forefeit if they don't show up.


Is it insecure to expose private bucket names through signed URL?

tl/dr: As long as the bucket is not publicly accessible (i.e. you need access keys to read/write), then don't worry about the name.  It
isn't private because your employees probably know it and
hackers/penetration testers routinely perform brute-force searches for
bucket names.  Also, asking "What if someone figures out how to hack
buckets?" is like asking, "What if the CIA planted malicious firmware
in all my computers?"  While theoretically possible, it probably isn't
your biggest concern.

It depends on what you mean by "private".
Actually Private
If you mean that the bucket has no read/write/access permissions from unauthenticated users, then revealing the bucket name in a signed URL doesn't matter because the bucket name is not sensitive data - the keys are.  Trying to hide the bucket name would just be security through obscurity, and in this particular case would add very little security.  Feel free to use signed URLs.
Merely Hidden
If you mean that the bucket allows public users to read/write/access it, and the only thing stopping people from doing so is that they don't know the bucket name, then yes, revealing the bucket name is a bad idea.  Of course for a bucket that contains private/sensitive data, this is a terrible way to manage your bucket anyway.  Hackers and penetration testers regularly find hidden buckets by using brute-force searching.  There are tools to make it easier.  As a result the only way to keep data in a bucket private is by denying all public access.
Threat Modeling
You also asked if you should hide the bucket name just in case some hacker finds a way to hack buckets knowing only the bucket name.  What you need is a threat model.  It's important to recognize that like all features in an application, every security measure has an associated cost (development time, possible loss of functionality, future maintenance costs).  Every security measure should also have a benefit.  As a result there is never really a point where something is "secure" or "not secure".  It's merely a matter of deciding when something is "secure enough", and each individual business is ultimately responsible for finding that point for themselves.  To get you started, I'll mention the risk you are concerned about and add some more to the list:

What if someone figures out how to hack an amazon bucket knowing just the bucket name?
Do you store you AWS keys in your code repositories?  What if one of your employees uses it to steal the data in your bucket?  After all, they already know everything anyway.
What if one of your employees wants to be able to make data available without a signed URL and so decides to just make the whole bucket public, forgetting that it also stores private data?

Personally, item #1 there would be the lowest on my list of concerns.  After all, something like 50% of all data breaches start with internal employees (either intentionally or not).  If someone did find some way to hack an AWS bucket knowing just the bucket name, it would be a huge deal.  It would generate world-wide headlines and Amazon would have people working around the clock until it was fixed.
Besides, you should stop thinking that you can keep a bucket name private.  You really can't.  Your employees probably all know it and they are as likely to cause leaks as "hackers" anyway.  Moreover, performing brute-force searches for buckets is a very common practice in both the hacking and penetration testing world.
Your bucket name isn't private.  It never will be.  Don't kid yourself into thinking otherwise.  Either way, there are an infinite number of possible things to be concerned about, and you don't have time to fix them all.  You need a threat modeling process to help you decide what is most important to your business, prioritize the potential risks for those assets, and then address them according to your available resources.


Is an attacker looking at encrypted non-boot partition able to tell if this is VeraCrypt, TrueCrypt or DiskCryptor?

No.

An attacker can not distinguish between VeraCrypt and TrueCrypt.
The reason for this is that they both share the volume format and guarantee a completely random looking container.

Concerning DiskCryptor, which seems to be an earlier fork of TrueCrypt, it looks like the header is also random-looking. The only difference may be measured if the drive is mounted, as the size of the volume, as TrueCrypt uses larger headers than DiskCryptor.

So by an offline attack no difference can be measured.


Restrict access to REST web application to authorized computers?

You trying to prevent a certificate from being copied from a computer that an attacker has full access to (as they would be able to run tools to extract non-exportable certificates) while at the same time having the certificate accessible for use by your application. This is simply not possible.


CSRF is an acronym used for Cross Site Request Forgery. It is an attack where a malicious website can transmit specially-crafted data to the vulnerable application on behalf of the victim, causing the state change in victim's account.

For the better understanding of the question for Android applications we can call it as Cross Application Request Forgery and for existence of this issue in mobile applications one application has to induce the state change for the other application installed on the device. Android supports the beautiful concept of application sandbox such that in the normal scenario one application can not access the data of any other application.

For successful execution of CSRF the session identifier(session cookie/session token) must be sent as the part of HTTP request for performing the state changing actions(which is the default behaviour in web browsers), it is highly unlikely to perform this kind of attack in Android applications since the attacking application won't be able to access the session identifier stored in vulnerable application sandbox to complete the attack.


Implications of using domain\computername$ account to serve SQL data to IIS

It makes no difference to the security of the web server.

In this case, the account you're connecting with will be the machine account, because the web application is likely running under the context of either:

The Network Service account
The AppPoolIdentity account.

In either case they're limited non-interactive accounts, and since the application is already running under the context of one of these accounts, there is no additional exposure to the web server or network that will be created by using the same account to access the database.  The expose to the database (and database server) will be determined by how you configure this accounts access, is is no different than the exposure created by using any other account configured the same way.

As to adding the account to the db_datareader and db_datawriter roles, that's not unreasonable.  It would be better if all data access were done through stored procedures and you could limit the account to the public role, but if it needs to directly access the underlying tables, then that is the minimum permission set required to access and update data and it's not terribly unsafe.  It does make it more important to account for any potential SQL injection attacks in your app.


If you don't set specific ip to $SMTP_SERVERS in the snort.conf, that variable is any. And flowbits works in pairs. For example,

alert tcp any any -> any any (content:"aaa"; flowbits:set, NAMED; flowbits:noalert;) <- session tracking only without alert

alert tcp any any -> any any (content:"bbb"; flowbits:isset, NAMED;) <- check pattern 'bbb' in NAMED session

Refer to http://blog.snort.org/2011/05/resolving-flowbit-dependancies.html


ECDSA/RSA certificates and cipher selection

You can only use the ECDHE-RSA ciphers from that list if all you have is an RSA certificate. Same thing for ECDSA certificates, which only can be used with the ECDHE-ECDSA ciphers on that list.

ECDH-* is fixed in the sense that your certificate contains the fixed public parameters for and key, which can be used for the key exchange. This certificate is then signed by a CA with either RSA or ECDSA, which leads to either ECDH-RSA-* or ECDH-ECDSA-* ciphers.

That being said, ECDH is not used much. I don't know what is your reasoning behind listing the ECDH(E) ciphers, but if you want forward secrecy, you should only use the ECDHE-* ciphers, as they generate different keys for every session.


Simple and secure remote installation method that accepts input via a web page?

Many such apps do not have a shell script part, and do everything through a PHP/Perl script instead.

I think we must consider what information does the installation have about who its master is. Certainly not "anyone who can connect through HTTP", since as you say, a bot might just scan for half-baked installation.

The simplest thing would be to require the same password used for FTP in order to proceed with the installation. This could be done by generating a random name such as .htABCDEFGH.txt and reading a cleartext password from it. In most installations the creation of such a file is only allowed for the FTP user, and the file itself cannot be read except through FTP.

A variation could be to let the installer choose a password, display its MD5 salted hash on screen, and require the hash itself to be saved server side, e.g.

To begin installation, you need to save the password you've
just chosen in a text file called password.php containing the
following lines:

<?php
    $INSTALLPWD='65cb963e760378ab0ee97e50ca70084f9555adb9';
?>

You need to do this via FTP, to prove you own the FTP account
used to deploy this installation.

Here again, unless one had the FTP password, one could neither write nor read the hash (even if the hash could be read, it could not be inverted).

For those installations that come pre-packaged with no FTP account (a popular choice in CMS web space providers), the password.php also could easily be generated by the CMS allocation script. After purchasing the CMS installation, you would be supplied not only with the link to the install and admin panel but also with the installation password matching the newly created password.php file.

Installation username would be possible in the same way, but it seems overkill. The installation password would only need to be used once, and briefly at that, to establish a chain of trust and let installation proceed. Once that's secured, you could define any user and password you wished (and delete the password.php and any setup directory/script, too).

For added security, the password.php script should not be used unless the installation is yet to begin. A fully installed system ought to ignore that file, to avoid anyone with a small exploit capable of creating one short arbitrary file to leverage this into the capability of restarting the whole installation.


Will checking origin and referer headers for CSRF protection block valid requests?

This depends on what you consider valid requests. If you expect all requests to be caused by navigation inside your web application then it will work unless you explicitly request that the Referer does not get send or if the user uses some kind of Referer blocking (browser extension or configuration). But, if you consider requests valid which come from accessing a bookmark in the browser or a link inside a mail then these will cause problems because no Referer or Origin will be sent.

EDIT: since according to the updated question your application does not expect GET requests to be state changing and thus you don't check these for CSRF bookmarks and links inside a mail should not be a problem and thus you can expect the Referer and/or Origin to be sent with each state changing request.


What is a typical response from webserver for POST request?

The question appeared to deal with the HTTP Response method chosen, and it's impact on caching.  See "POST Caching" below for the answer to that question.

Clarifications by the OP in comments suggest that the security team is concerned with the browser remembering values entered into field forms, such that they're accessible to 'back' or 'autocomplete' usage.  That is completely unrelated to the HTTP response that the server chooses to issue; even if a redirect is used, that just increases the number of 'back' clicks necessary to return to the information.

The HTML form autocomplete attribute and HTML input autocomplete attribute are used to request that the browser not remember the values entered.  However, these are requests, not prohibitions.  Browsers can do whatever they want, and have been known to ignore or misinterpret these tags, and to exempt anything they find interesting from being subject to them.  Chrome, for example, has had this thing where "off" doesn't work but "false" does.

So - there's things you can do to help it, but not to control it.  And a 302 instead of a 200 isn't one of them.

POST Caching

A POST with a 200 response will not be cached unless additional HTTP headers in the response specifically request it.  See Is it possible to cache POST methods in HTTP? from StackOverflow; to quote their quote of RFC 2616:

  9.5 POST

  ...

  Responses to this method are not cacheable, unless the response
  includes appropriate Cache-Control or Expires header fields. However,
  the 303 (See Other) response can be used to direct the user agent to
  retrieve a cacheable resource.

Your security team had a good thought, but failed to ask if the architects of HTTP managed to have the same good thought first.

In practical terms, this is why your browser prompts you when you try to reload a page that was the response to a POST form submission - it tells you the request will be retransmitted to the server, because the browser did not cache the original response.


How is VPN tunneling actually implemented?

Roughly speaking, when you do anything on the Internet, you do so through a network interface. That is the thing that "has an IP address". You can have several interfaces on your system (for example Ethernet, WiFi, and the "loopback" interface that allows two programs to talk to each other through the "internet" even if you are offline.
VPN software simply tells the system there is another interface, let us call it "vpn0". The system asks the interface, "do you have an IP address?" and the VPN software answers "Yessirree, it's 150.217.256.35" (yes, that 256 is both impossible and intentional).
Then, the VPN software (usually) also publishes a route, i.e., it says, "addresses from 150.217.0.0 through 150.217.511.511 are reachable through this interface" .
So whenever some program on the system wants to reach, say, 150.217.432.234, the packet will get sent to vpn0.
If the published route is the default route for anywhere, then all packets (except loopback and local ethernet and wifi) will be routed through vpn0.
The VPN software might also publish new DNS servers, so that if some program such as Google Chrome wanted to reach www.nekkidgals.org (haven't checked, but it probably exists), it would ask that DNS instead of, say, 8.8.8.8. So also the packet asking "what is the IP of www.nekkidgals.org?" would go through vpn0.
Now vpn0 is actually a software driver, and this driver encrypts the packet. It can do this in any of several ways.
For example, before vpn0 even exists, it could connect (through eth0 or wlan0, both insecure) to a known VPN server and ask for a public key. Then it could choose a very large symmetric key for, say, AES-256 algorithm, and send this key to the server after encrypting it with the server's public key. So, even if someone was to listen on the insecure wlan0, it could not decrypt the AES256 key since it would not possess the private key. The server, meanwhile, having that private key, is now in possession of the AES256 key. VPN client and VPN server start exchanging packets protected by AES256 through wlan0.
Each time the user believes he's sending unencrypted data through vpn0, that data gets encrypted and sent to the VPN server via wlan0. There it gets decrypted and continues its journey, but now it appears as if it originated inside the network of the VPN server.
As you can see, it is important that not only the connection is encrypted, but all the routes must be covered and DNS needs also be tunneled through VPN. Otherwise, someone could still guess what you're doing from the DNS queries sent in the clear.
Apart from this detail, your computer remains unchanged, so for example if you have spyware or malware aboard, it will still work; if you or some software can be tricked into not using the VPN for something, you can be traced; and your browser is still your browser, with its cookies, its supercookies, its audio-context fingerprint, its unique combination of versions, fonts, resolution and whatever; so it can be recognized.


How can one test if a password generator is cryptographically secured?

It is very hard to evaluate the quality of a random password generator without knowing its underlying algorithms. The quality (the entropy) depends essentially on 2 elements:

the number of possible combinations
the equivalence of probability of different combinations

The problem is that a random generator that would iterate over 10 millions random password phrases will be a very poor password generator if the attacker could know the used passphrases. But if you only use several thousands of generated passwords it will look very good.

If you really know nothing, you can do little more than testing a rather large sample for collisions: if at least one password occurs more than once, chances are that the generator has a low entropy. But unless you can test for very large samples (the magnitude order of the expected entropy) no collision is not a sufficient proof of quality.

So my advice is: if you do not know enough from the generator, just do not use it.


HTTPS is always recommended these days. And generally fairly easy to implement too.

Any webiste that contains sensitive information or any that simply has a login MUST be secured with HTTPS. Othewise, you are sending information in clear text over the Internet which is easily intercepted.

For sites with no login and no sensitive information, HTTPS is perhaps less critical but there are still reasons. The main one being that without it, it is possible for attackers to substitute some of your legitimate content with their own. When using HTTPS, the end-to-end conversation is encrypted and so attacker have no way of intercepting and replacing content.

The other main reason to want HTTPS always is to stop 3rd parties from following what you are reading.

These apply to the website you listed. Although the store part of the site is already secured with HTTPS, the general sections are not, by default, and so may be vulnerable to attack and eavesdropping.

You should note, however, that having a general website only use HTTP is still very common and the risks are generally not that bad.

Note: Try using HTTPS on that website, For me, it completely messed up the formatting. So something is not correctly configured.

Regarding login pages: It is best practice to encrypt the login page not just the actual login dialogue. This ensures that the end-to-end communication is encrypted and it provides visible assurance to the user that you have done the right thing. Never give your login details on a page that isn't using HTTPS. Not for any reason. You probably don't have time to go round checking what the system is doing behind the scenes and it indicates poor understanding and/or practice on the site owners and developers parts.


What exactly determines what version of SSL/TLS is used when accessing a site?

As @Terry says, the client suggests, the server chooses. There are details:

The generic format of the first client message (the ClientHello) indicates the highest supported version, and implicitly claims that all previous versions are supported -- which is not necessarily true. For instance, if the client supports TLS 1.2, then it will indicate "max version: 1.2". But the server may then elect to use a previous version (say, TLS 1.0), that the client does not necessarily want to use.
Modern clients have taken to the habit of trying several times. For instance, a client may first send a ClientHello stating "TLS 1.2", and, if something (anything) fails, it tries again with a ClientHello stating "TLS 1.0". Clients do that because there are poorly implemented, non-conforming TLS servers who can do TLS 1.0 but reject ClientHello messages that contain "TLS 1.2".

An amusing consequence is that an active attacker could force a client and server to use an older version (say TLS 1.0) even when both support a newer protocol version, by forcibly closing the initial connection. This is called a "version rollback attack". It is not critical as long as client and server never accept to use a definitely weak protocol version (and TLS 1.0 is still reasonably strong). Yet this implies that a client and server cannot have a guarantee that they are using the "best" possible protocol version as long as the client implements such a "try again" policy (if the client did not implement such a "try again" then the rollback attack would be prevented, but some Web sites would become seemingly unreachable).
The ClientHello message for SSL 2.0 has a very distinct format. When a client wishes to support both SSL 2.0 and some later version, then it must send a special ClientHello which follows the SSL 2.0 format, and specifies that "by the way, I also know SSL 3.0 and TLS 1.0". This is described in appendix E of RFC 2246. Modern SSL clients (Web browsers) don't do that anymore (I think IE 6.0 still did it, but not IE 7.0).

RFC 4346 (TLS 1.1) specifies that such SSLv2-format ClientHello messages will be "phased out" at some point and should be avoided. RFC 5246 (TLS 1.2) more clearly states that clients SHOULD NOT support SSL 2.0, and thus should have no reason to send such ClientHello messages. RFC 6176 now prohibits SSL 2.0 altogether.

Now a RFC is not a law: you don't go to jail because you don't support any particular RFC. However, RFC still provide guidance, and thus somehow illustrate what will be the state of things in the near (or far) future.

In practice:

Most clients out there will send only SSLv3+ ClientHello messages, and will happily connect with SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2, depending on what the server appears to support (but, due to the "try again" policy, a version downgrade can be forced upon by an active attacker).
Actually, some clients won't support SSL 3.0, and require TLS 1.0.
Similarly, some clients won't support TLS 1.1 or 1.2. Web browsers have been updated in the recent years (in the aftermath of the bad press resulting from the BEAST attack) but non-browser applications are rarely as aggressively maintained.
Many server still accept a SSLv2 ClientHello format, as long as that ClientHello message is a SSLv3+ ClientHello in disguise.
A few servers, like yours, are still happy to do some SSL 2.0. This does not conform to RFC 6176, and is frowned upon (people who believe in "grading SSL servers" will give you a bad score for that). This is not a serious security issue, though, as long as clients don't actually support SSL 2.0. Even if a client supports SSL 2.0, it should include some rollback-prevention trickery (described in RFC 2246) so a rollback down to SSL 2.0 should not work.

You still want to deactivate SSL 2.0 support in your server (not necessarily SSLv2 ClientHello format, but actual SSL 2.0 support), if only for public relations.


Should SSL be used in purely informative page

Authentication

Authentication helps verify ownership of your website. Believe it or not, there are people out there that make replicas of websites and divert traffic in an effort to steal from you.

Most people know that they need to check for the green lock in the URL window before entering personal information into a website. But you can go one step further and verify the SSL certificate to make sure your visitors know their information is safe on your site.

Data Integrity

Data integrity is about whether the data on your site has been tampered with while it’s in transit. If someone knows what they’re doing and your website is not secure, they can tamper with the data transmitted from your server back to the client. The contact form a potential client just filled out on your website could go to a hacker and not to you.

Encryption

Encryption refers to the security of communication between the client and the server so that no one else can read them. This is a key point for commercial websites. While it’s extremely important to encrypt the communications on an ecommerce website, it’s equally important to encrypt the data submitted using forms.

for more details click here

Google Says HTTPS and SSL is a Necessity

Google has confirmed that it uses HTTPS as a ranking signal when showing search engine results. This is a good thing for your business, as it gives you a competitive advantage against businesses who do not have an SSL certificate on their site.

Google also states that if your website does not use HTTPS that not only will your search engine rankings be affected, but your website’s credibility will be affected as well.

In July 2018 Google began displaying the security of the connection in the address bar of Chrome on all website pages, marking all HTTP pages “Not Secure”.


Can a static IP address be a trusted user identifier in a secure environment?

There are several problems with IP-only authentication.

It is not, by itself, secure. A man-in-the-middle attacker can pretend to be the expected host at any IP address, and spoof anybody they want. If you want to prevent that, you'll still need an authenticated and secured channel, such as IPSec or TLS.
An attacker that doesn't need to see response messages can still send requests to the server, if the server supports UDP or protocols that don't require a bi-directional handshake prior to sending any data.
It's brittle. If the IP address ever changes, for any reason, not only will your authorized host lose access, but whoever happens to get the old IP (by luck or by malice) will now be treated as authenticated.

I strongly recommend another approach. Mutual TLS/DTLS is a good option for Internet-based connections where you control, or at least can coordinate, both endpoints. Standard TLS (which only authenticates the server) also works if you have some other way to authenticate the client, such as a password or other pre-shared credential, though then you have to protect against all the standard attacks on authentication systems. Adding IP filtering on top of [D]TLS is generally fine, aside from the brittleness risk


how do extended validation X.509 certs work?

These values (both OID and root CA cert fingerprint) are indeed hard-coded in the browser's code. In Firefox, this is done in nsIdentityChecking.cpp.


What are the security best practices for clients authenticating users with password against LDAP?

For most deployments checking the password via LDAP simple bind is the best solution. Especially because most LDAP server implementations apply password policy restrictions (pw expiry etc.) only when processing bind requests.

However there is an interesting use-case for using compare requests:

In a really paranoid LDAP setup the application would bind with a service account and would then be explicitly authorized via fine-grained ACLs to check the password on behalf of the user. Such an additional security boundary is nearly not possible with bind requests because those are always anonymous (besides looking at peer's IP address or similar).

P.S.: There are several flavors of pass-through authentication. If you have a LDAP application-level proxy you can of course forward compare requests to other LDAP servers.


I find missed step. After Success-Response (from client) on phase2 I need to write empty message. I.e. TLS-ASK packet needed before phase1 Success (from server).

Now it works with linux, android (wpa_supplicant). Not works with iOS...


Android shared library integrity protection

No.  There's no way to do this securely, in a way that will resist serious dedicated attack: the owner of the phone will be able to modify the copy  of the library that is stored on their phone.  Once rooted, it's their phone, after all.

You're basically asking for software that is resistant to reverse engineering.  We have extensive experience (based upon copy protection, digital rights management, and other schemes) showing that while you can make reverse engineering a little harder, you can't prevent it.

Why do you want to prevent the owner of the phone from modifying their own code?  Maybe there are other solutions to your problem.


BCrypt Tables for 6 digit numbers 000000-999999

What you're looking for, in theory, is a thing called a "rainbow table", a lookup table of hashes to their original outputs. There are quite a few of them online (and they tend to be huge, containing far more than the mere million entries for "000000" to "999999"). They're most common for simple hashes (MD5, SHA1, etc.).

Unfortunately for you, bcrypt requires the use of a very standard technique for defeating rainbow tables: a salt that is combined with the password before hashing, meaning the range of passwords you need to check is essentially many orders of magnitude larger than the simple million values you're checking for.

Bcrypt actually requires a salt, so there's definitely one in there. I believe that in your example it is the lzzo9IuiAWyIs2H4NI4w1. part (the first 22 base64-encoded characters following the third $, as per Wikipedia's description of the algorithm). The salt has to be stored in plain text, but it means that any rainbow table created without using that specific salt is useless for cracking the output (and no pre-computed table will use that specific random salt).

Somebody could reuse a single salt (with at least some bcrypt implementations, this is possible) but salts are supposed to be generated uniquely for each password. Check whether the first part of the hashes (following the last $) that you want to reverse is different for each value. In any case, the existence of salts at all means a pre-generated rainbow table isn't going to help.

On the other hand, a million entries is a pretty small search space. Bcrypt is a somewhat old password hashing algorithm (notably, it lacks the tunable memory cost parameter that newer functions have, although most people don't have easy access to the hardware that can brute force it most quickly). For simply using a commodity CPU, the difficulty of brute-forcing depends on the "cost" or "work factor" parameter. In your example, this is 04 (the number between the second and third $), which is low by modern standards. You can certainly brute-force any given 6-digit password in under a day (worst-case, that requires just under 12 hashes per second, which should be easy at cost 4). If they aren't using unique salts, this is equivalent to building your own rainbow table and allows reversing all the hashes.

Building a rainbow table just consists of hashing a bunch of inputs (in this case, the full million possibilities), preserving the password < > hash mapping, and sorting by the hash outputs. They can take a while to compute, depending on how slow the hash function is (for a "cost" of 4, pretty quick), how much you can parallelize it (if you have a multi-core machine, each core can work on a different set of passwords; modern CPU caches have no problem with the memory cost of bcrypt), and how many entries you're trying (some rainbow tables have a billion entries; a million is nothing). They also require storage space, but for one table with only a million entries it should take less than 100 MB of storage.


How to securely store sensitive data on mobile application?

Just use TLS, it's what it was meant for: securely send data between two parties across an untrusted channel.

Should you want additional protection, there are two ways to solve this problem that spring to my mind:

Use a password to encrypt the symmetric key
Use a token such as an OTT through SMS or generated using a smartcard and external cardreader with a challenge/response

The first option will password protect the symmetric key, the side effect is that the only secure way of implementing this is that the password is only saved temporarily in memory. This will require the user to input his password to decrypt the symmetric key every single time your program requires to use it.

The second option is what I've seen implemented plenty of times and does not require a key to be stored on the device. They use the bankaccounts card and an external card reader. You generate a challenge server side and send this over TLS (don't forget certificate pinning!) to your user. The user inputs the challenge in the card reader which generates a response. Client then sends the response to the server which can be verified by the server.

Remember that it's all about risk assessment, the likelihood someone is able/wanting to go as far to get your mobile app needs to be assessed. As a first recommendation ensure that you build in checks to verify if the device is rooted/jailbroken or not. If you find that the phone is jailbroken simply do not allow usage of your app and make sure to put it in the terms and conditions that the risk of loss of money is the client's responsibility when using jailbroken/rooted devices (allthough you still also need to account for reputational damage).

Make sure you have plenty of sanity checks server side as well to see where money is going. If suddenly a user is sending way above average amounts of money to accounts in Eastern European countries, it might be a good idea to temporarily block the transaction and actively call the customer to see if he intented to send that money.


PCI prohibit direct outbound connections on EC2

Section 1.3 is intended to prevent repositories of sensitive information (in PCI DSS world - cardholder datastores and processing engines) from being able to either offer an internet-facing service, or push data directly out of their store to the internet.
The concept behind the first part is to minimise the attack surface available to an unfriendly outsider, and the second part is to provide some defence in depth, so that if a breach occurs, there is a barrier to an attacker simply piping data out to their location.

As with a lot of PCI DSS, if you can avoid storing data post-authorisation you will save yourself heartache (and costs). It might be worth considering whether you can get the results you want using a payment service provider like worldpay instead of rolling your own payment system.

A lot of "reference sites" to PCI DSS are simply vendors looking to push their products as the solution to PCI DSS (tip: they are not, usually), however the PCI Council is worth reading through, as is Amazon's AWS Reference (since you are using EC2)


Digital signature: How do I know what I'm signing?

In general, you (or anybody else with your public key) can verify a signature on another machine, which is generally good enough to ensure that the data being signed wasn't tampered with. You could also try calling the signing code directly, passing a byte buffer that you control, and making sure that it verifies the way you'd expect.

I don't know exactly how PDFs store digital signatures, so I'm not sure how you'd go about creating or verifying one manually (without using the software that you don't trust). However, there are definitely multiple PDF programs, so maybe you can use them to get some degree of additional trust.

With all that said, exploiting something like this would be very difficult. An attacker would need:

A document (or possibly other data blob) that they want you to sign.
A way to get this data onto your computer, and compromise your signing tool so it gets substituted for the data you meant to sign.
A document that you will (attempt to) sign, but that will accept the invalid signature.
A way to get the spoofed signature back from you so they can add it to the maliciously-chosen data.

This is all possible, but it's not generally going to be a significant threat. If you want to be sure, verifying the signatures on your data, using a different computer and ideally a different program.


Well Simple answer.

DO NOT EVER INCLUDE ANY KIND OF PERSONAL INFORMATION INTO URL.

URL is extremely easy to get from outside (e.g. javascript, screenshot, etc etc) and it should never, ever include personal information. It's like using a Social Security Number as your license plate number.

You technically can block bruteforce scanners by adding checks like if the user is in the current session and reject connection if anyone is trying to access to the URL without session information, but it's still not great approach because it will still give you some sort of response from server. (for example, if you just check session and echo that you have no permission, it will give you 200 response code, and the attacker will be able to notice that there is SOMETHING)

Please find other ways to provide your service without using personal information on URL.

As suggested below, if you decide to hash the personal information, please use longer & more character set.

If you use only 6 alphabet characters, it will take about ~9 hours with Class A brute force attack, and Class F can crack it instantly.

Please take a look at this website and make sure you hash it correctly. But then again, hashing should not be the ultimate solution.

EDIT:

If you are not displaying personal information on URL, that might be fine. You can simply generate a personal link and send it to your user via SMS or email with authentication.

That means, once user clicks the link, it will take the user to the login screen. The URL should not mean anything in this case of course.


Application vs Device - Data encrypted at rest

It's difficult to say for certain without knowing which MDM platform you are utilizing.
I can tell you from personal experience that Mobile Iron containerizes and encrypts data without requiring full device encryption.

Does Web@Work secure cached data?
Yes. All cookies and cached data is encrypted as a part of the
AppConnect container. This data can be wiped as a part of a selective
wipe, should the device fall out of compliance.
How do you make sure a rogue app does not capture corporate data?
MobileIron AppConnect encrypts and stores all AppConnect Enabled (ACe)
app data in a virtual container on the device. Rogue applications
cannot access the data stored in the virtual container. In addition IT
administrators can also define policy on how data is shared between
ACe applications.
What kind of apps does AppConnect work with? HTML5, etc.
AppConnect can secure both in-house and 3rd party applications.
Security for HTML5 app is provided by the AppConnect enabled
Web@Worksecure browser. A complete list of AppConnect enabled 3rd
party apps is available here. In addition to device-at-rest
encryption, AppConnect also leverages per-app VPN to secure
data-in-transit.


Are "Security SMS codes" any safer than plain SMS?

It's not actual 2FA but 2-step authentication. As linked by StackzOfZtuff they are in fact plain SMS messages.

The reason it's two step and not two factor is because two-factor would imply you need true possession of the object where the token is generated and there has to be assurance the token cannot be intercepted by another party. This is where SMS is flawed. SMS has a few known vulnerabilities which would technically make it possible for interception:

Compromised GSM network
False base station attacks on older versions of the GSM protocol
SIM card cloning

That said the messages are indeed sent using SMS gateways. So is it in fact fool proof way of authentication? Probably not. However each bank does a risk assessment on what the likelihood is of attackers performing the above attacks with the purpose of stealing bank accounts and probably realized the likelihood would be low. It would require a lot of effort in case of SIM cloning or false base station attacks versus the return on investment. If someone manages to compromise a complete cellphone carrier, then there would probably be more valuable attacks to perform than targetting individual bank customers.

Furthermore most banks often require additional confirmation mechanisms to perform actual transactions (but this depends on the bank of  course). For instance my bank will not allow me to send transactions to accounts to which I have not sent money before. Otherwise I need to sign the transaction with a card reader.