Doesn't persisting previous passwords pose a vulnerability? Recently I attempted to log in to Facebook, but I'd forgotten that I'd changed my password. Facebook bounced me back to the login screen and advised me that I'd attempted to enter an old password.

Covered thousands of times, if not more, in various articles/threads are reasons justifying the need for password expiration. It's, basically, best not to keep using the same password forever. So I'd have assumed that this translates to it being best that the same passwords aren't held in a DB forever.

Question:

With old passwords still in the DB, then has the system (e.g. Facebook) not disregarded, what is thought as, a safe security measure?

I can see a couple of potential issues with a solution like this:

If a users (old) password is compromised, then an attempt to log in with it can be used to confirm that the user exists, and has an account - probably not a big deal in the context of FB, where most accounts are searchable anyway, but I still think the principle holds in general.
If someone suspects that they have your password, this can be used to at least confirm that the user has a specific password previously. For the average users, chances are good that that same password will be used for any number of other services too then.

Those two hold even if a user has a good password (ie. a long string of hard-to-guess characters). Since the average FB user is likely to use the name of his or her cat/dog/child/hamster/boyfriend/girlfriend/whatever instead, then being able to confirm the previous use of a certain password can provide insight that may help someone guess a new password too.

As a concrete example, I know of someone who for a long time used the following scheme based on the names of their children (names changed, obviously):

First child: Mark
Second child: Emma
Third child: Carl

Based on those, the user would switch between passwords like this:

MarkEmmaCarl
MaEmCa
MarEmmCar
...and so on.

Sure, guessing a next password based on some quasi-random scheme like this may still require a significant amount of work, but a lot of it can be automated, and it will in any case be far easier than for a random string.
If you can establish a pattern by confirming the existence of one or two previous passwords like this however, then you have a pretty strong incentive to keep trying...


Encrypting with Mongo How can I achieve the following goals?

All compute and storage to be located in the cloud.
Encryption in transit of all data between web nodes and db nodes running MongoDB.

How to set up tunnels? Which protocols/tools?

Encryption at rest of all data stored in MongoDB.
All data is backed up (also to the cloud) frequently.

Backups are encrypted in transit and at rest.

All encryption and key management concerns are handled in the infrastructure, not in the application.

Should not require any changes to the application code.

Keys for all at-rest encryption can be rotated regularly.

The key rotation process is simple, scriptable, automatable.
Data stored in the past should be retrievable at any time, even after arbitrarily many key rotations.
Backups should be retrievable for some period of time: they should survive at least one key rotation.

Please post, even if you only have partial answers or answers to a single bullet point. A solution to one sub-goal is part of the solution to the overall goal.

Thanks in advance for your answers!

Your requirements aren't cloud specific.  This same solution will work with a traditional hosting.  The hallmark of cloud computing is dynamic resource consumption by booting up VM's only when you need them.

1)As far as I know MongoDB doesn't support SSL.  In order to have a secure connection to MongoDB you'll have to use a VPN to create a safe tunnel.

2)It is almost always better to encrypt the data prior to inserting it into your database.  From a secuirty perspective if your database is taking care of encryption then it requires a key and the database is compromised then the encrypted data is also compromised.   This should be taken care of by your application,  also note that a stream cipher will produce smaller messages and save space.  Stream ciphers are safe if used properly,  (unique IV for each message).

3) There are many backup services that use encryption.   If you are rolling your own then i recommend using the open source project Bacula.


Proper security for IoT device I'm developing a product with simple Cortex-M MCU (with no OS on board, firmware on bare metal) and internet connectivity via external module.
How do I make it secure? More specifically, how do I protect the data that is sent to and from the remote server?

My thoughts are:

I can't assume that firmware can be protected; since all users will have physical access to it - they eventually will find a way to dump it. Flash-read protection won't work, encrypting the flash won't prevent dumping it from RAM or something else.
Using external encrypted flash/eeprom won't work for the same reasons.
Relying on HTTPS on the external chip won't be enough because external module is connected to the MCU via UART and can easily be sniffed or tampered.

I have very basic understanding of cryptography but I know that I shouldn't invent my own, so I presume I'll have to encrypt all the data that is sent to the server by some well-known public key crypto. Probably using session keys.
But that still requires using one master secret key on the device and I don't know how to store it securely due to 1).

Any ideas? Is there a well-known bulletproof solution?

Or I should just generate random keys for every device (not derived from device ID or anything like that)? So if one device is compromised it won't affect the whole network - and that's about it?

UPD: Clarification - I don't want to allow device owner to impersonate other devices and upload false data (about other devices) to the database.

More specifically, how do I protect the data that is sent to and from the remote server?

I'm not sure if I properly understood your question. But I understand the above part that you just want to protect the data in transit between client and server. In this case HTTPS (or plain TLS) is enough. This will automatically use different encryption keys for different TLS sessions (where TLS session will have the same lifetime as the TCP connection unless session resume is used)  so the risk you imagine of having the same encryption key on all devices does not exist.

But HTTPS or TLS will not protect against somebody who has physical access to the device and intercepts the data there before encryption and after decryption. It only protects the data in transit.


dealing with small businesses and security issues I am dealing with a small business that I have no choice right now but to deal with. I do not work for this business but my personal life dictates that I use them right now. I noticed a few months ago that they have a wireless network setup with WEP encryption (and a really weak key...don't ask), no MAC filter and the admin port is open (HTTP as well).

I brought it to the attention of the person in charge and explained to her that they needed to change their setup. I was told they outsource their IT to another local company (most likely just another guy that lives around here).

I wrote a note with a few suggestions to make it more secure, about as good as you can get on the $60 Linksys router they are using.

I noticed the other day (a few months later now) that it still hadn't been changed. I asked her about it and she said that the IT guy said that everything is fine the way it is setup.

I explained to her again that it was not fine.

Now, this place doesn't have my credit card or anything like that on file, but they do have all the personal information of me and my family and other families.

Any suggestions on how to deal with this? Other than to find another business which just isn't possible right now.

No matter what size the business, in my experience the only three ways to get a provider to move on this are:

Financial: Tell them you'll take your business elsewhere - I understand this isn't possible here.
Regulatory: If they are dealing with personal information they must provide appropriate protection in most jurisdictions (eg DPA in the UK -  so the threat of a review by the ICO might work)
Reputational: this isn't meeting what most would class as good practice. You wouldn't want to recommend them to your friends and contacts would you? A threat of disclosure makes it a financial incentive for them - they risk losing business.

For now get them to agree in writing that they take full responsibility for your personal data being hacked/copied/tampered through substandard wireless controls :-)


Confused about symmetric 128,256 key and the secret provided I have searched and searched but cannot locate an answer to my question so I am hoping the experts here can.

When I read about symmetric encryption like AES I see mention of the key and key size such as 256 bit keys. When I code in PHP and use AES I provide a secret or paraphrase. Is the secret that I provide the key?

If so, does the secret which is basically a string in coding terms need to be 256 bits long?

The passphrase is used to derive a key from using a hashing algorithm which turns the passphrase into a fixed length series of bits.

Most implementations will use the PBKDF2 hashing algorithm to generate a hexadecimal key of 256-bits. The easiest way to do this is to use PBKDF2 with SHA-256.

An important note though, AES itself doesn't care about how the key is derived, all it wants is something which is 256 bits long. How you generate that key is beyond its scope. There are bad ways to generate keys and there are good ways. The above mentioned method is considered a good one. If you want to know more about how key derivation works, I suggest reading this wikipedia article.


Which is faster - brute-forcing, or using a dictionary attack that contains all possible permutations? Assuming a 6-character password uses the mixalphanumeric charset, giving each character a character set of 62 and the entire password a keyspace of 62^6 = 46.6 billion (if my calculations are correct)...

Would it be faster to brute-force the password, or generate the entire keyspace in a dictionary and use that dictionary in a dictionary attack?

Are the two approaches considered equivalent, or would there be a difference in performance? Is the latter often done? If not, why not, and if so, why isn't it more common?

Note that the example mentioned is just that, and the question I'm asking is a performance one regarding the two methods, irrespective of a particular password's keyspace and actual time taken.

There is no difference ... until you get into the implementations.

Efficient cracking platforms like hashcat and John the Ripper execute bruteforce directly on GPU/CPU using optimizations that make them far faster than equivalent candidate passwords could be fed into the cracking process from an external dictionary.

True bruteforce and related attacks (like mask-based and rules-based attacks) should always be faster than a pure dictionary attack.

Update: My answer applies for fast hashes. Pascal is right in his answer that if the hash is slow enough, it would be the same.


Vega shows SQL injection vulnerablity but sqlmap says no I'm pen testing an application. The URL is basically app.php?app=appname. If app exists it gives correct output, but if it doesn't exist we get a internal server error 500.

Vega detects it as a SQL injection vulnerability, but when I test it with sqlmap it cannot find injection in this url. Vega shows the URL app.php?app=appname'%20AND%201=2%20--%20, but it also gives the same internal error.

In this case is it really a SQL injection vulnerability? Can I force sqlmap to use this URL as a help?

If the application is querying a database for appname, then most likely you have a SQL injection. To test the url with sqlmap run the command:

sqlmap -u "app.php?app=appname" -p "app"

Here is a quick cheat sheet to protect yourself from SQL injection.


Are popular porn sites more likely to be infected with malware? I'm trying to help my friend understand this because he believes that since a site is very popular, that it's less likely to infect its viewers because of its security! Is a popular site less likely to infect its viewers?

Please answer this question as detailed as possible so I can direct him to this site.

I think it's generally popular sites, not just porn sites. However there might be some reasons why pornsites tend to attract more malware.

Mostly malware originates from dodgy advertisement platforms. Because the morality of porn is  often debated and not accepted in every culture, a lot of larger advertisement websites, such as Google Ads, do not allow their advertisements to be published on a porn site. This means that porn websites need to turn to somewhat dodgier advertisement provider to get money (porn sites make money from ads). One thing that happens is spreading adware and even right-out malware through these advertisements.

There is an interesting article "Porn Sites Aren't (Always) Dens of Malware" on pcmag's security watch. There's also Dynamoo's blog who did analysis on this. Xhamster has had issues with this before:

  The problem is that even reliable advertisers sometimes can be hacked.
  For example, in the past we had such issues with one of the top five
  porn paysites in the world," xHamster told the BBC. "Now our reliable
  partners are checking new advertisers very strictly, so it's almost
  impossible to put a new site with malware on xHamster.

The conclusion of the article is that it's not inherent to porn websites alone, but generally popular websites.

  It's easy to dismiss this as a problem reserved for a reviled, fringe
  industry but that is simply not the case. According to Bob Hansmann,
  security research marketing manager at Websense, any site which draws
  traffic is a potential target for malvertising.

  "Past research by the Websense Security Labs has actually illustrated
  that popular beats porn when it comes to malicious content," Hansmann
  told SecurityWatch.  He explained that even blocking access to
  so-called risky content like porn and gambling would do little to
  protect against malvertising attacks.

  "Such threats are now more common on ‘business’ and ‘technology’
  sites," he said. "Malware is everywhere."

  It's worth noting that the ranking service Alexa lists xHamster as the
  46th most popular website on the Internet, and Pornhub the 63rd. Of
  course, malvertisers will tailor their ads to appeal to what they
  perceive their victim's preferences to be but they would do this for
  any site.

  Just a few months ago, Google detected malicious ads on the New York
  Times and HuffPo. The issue was malicious content being delivered
  through the NetSeer advertising platform. For a while, the popular
  Google Chrome browser blocked access to these sites. Hansmann pointed
  to similar attacks affecting Spotify and the London Stock Exchange.


What are the risks in specifying localhost as an "Authorized Javascript origin" in an OAuth configuration My application uses Google's OAuth for authenticating users.  For development/debugging purposes I want to be able to run it locally (on my dev. machine). To have the OAuth login functionality work in this mode I can configure the OAuth such that http://localhost:<some_port> is whitelisted as an authorized origin (see screenshot, below).

My questions:

What are the security implications of this?
Are there any other ways to achieve that? (I believe I can run a local forward proxy but I am not sure how to get it to work with HTTPS)

Generally it means that one can trick Google (or another Authorization Server) to send a valid authentication token to localhost, from a client point of view.
Assuming that for that client "localhost" will always resolve to a 127/8 address, and those is handled on a local interface; if another process is listening on that port, it might be able to steal that token.

If, somehow, with a particular configuration your machine would try to append your domain (e.g .domain.com) to "localhost" query; someone could poison that, and you'd send your auth token to an arbitrary host.


IPTables default security rules for a gateway/router? On a router such as dd-wrt or tomato, what would be some default iptables rules?

I am asking for rules on a router/gateway - For example; blocking SYN flood attacks, or XMAS attacks. The basic iptables rules that are a must for a router/gateway. Sort of like how anti-virus is 'defacto' when securing a computer.

Right, so this is is a Hard Questiontm. Since all environments are different, it is very tricksome to provide a "One Size Fits All" ruleset that one can expect to just drop in. Any such configs, config snippets, recommendations, etc, must be fully grokked and tweaked to work in your environment. That being said, as discussed in the security.blogoverflow.com post (and in much greater detail), Base Rulesets in IPTables, this is a pretty basic set of sanity checks that I've built out over the years and have been recommending to people.

## Section 1
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type any -j ACCEPT
## Section 2
# Force SYN checks
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Drop all fragments
-A INPUT -f -j DROP
# Drop XMAS packets
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# Drop NULL packets
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
## Section 3
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
###
# Insert your system specific rules here
###
## Section 4
-A INPUT -j LOG --log-level 7 --log-prefix "IPTABLES Dropped: "
-A INPUT -j DROP

Section 1

This is you pretty basic accepts. In general, you just want to allow ping and any localhost traffic or else things may not necessarily work as expected.

Section 2

This is a series of quick and dirty checks for known wonky packets that can cause problems. The only reason we put this second is for performance reasons.

Section 3

Here we allow all packets that are part of an existing session to come in. Most firewall admins would say to put this at the beginning of the config, performance reasons and all that. However, I would rather wonky packets be blocked even when part of an on-going session.

Section 4

Here is our log and default deny. The downside of putting the log message all the way down here, is that we won't get notified if any the wonky drops are triggered. We could move it up to the top, but that would either:

Make our config really messy
Overwhelm the logging engine

Really, it's your choice. As a generic recommendation, I opted for cleaner so that it would be easier to understand.


Why do I hear about so many Java insecurities? Are other languages more secure? I really like the Java programming language, but I continuously hear about how insecure it is. Googling 'java insecure' or 'java vulnerabilities' brings up multiple articles talking about why you should uninstall or disable Java to protect your computer. Java often releases a huge number of security patches at a time, and yet there are still tons of vulnerabilities left to patch.

I understand that there will always be bugs in software, but the amount of vulnerabilities Java has had does not seem normal (or am I imagining that?). What's even more confusing is that if there is a single architectural decision that is creating these vulnerabilities, why not change that design? There are tons of other programming languages that don't have this problem, so there must be a better way to do whatever Java is doing wrong. So why is Java still so insecure?

If you use Java like most other programming languages, e.g. to write standalone applications, it is no less secure than other languages and more secure than C or C++ because of no buffer overflows etc.

But Java is regularly used as a plugin inside the web browser, e.g. similar to Flash. Because in this case the user runs untrusted code without having explicitly installed it, the idea is to have the code run inside a limited sandbox, where it should not be able to somehow act against the system or the user (e.g. read local files and send them to the website, scan the local network etc). And this is where Java failed in the recent years, e.g. new bugs popped up sometimes on a daily basis which allowed escaping from the sandbox.

Also, sometimes bugs in the byte code interpreter or native libraries lead to buffer overflows and could compromise the system, but in this regard Flash is usually considered worse.

And as for the other languages being better: these usually can't even run as untrusted code inside a sandbox (exception is JavaScript and maybe Flash), so they would be even worse because there is no inherent way to limit their interaction with the system.


Is my passwordless auth (magic link OTPW) system secure? I've implemented a passwordless auth system (where the users only login using a 'magic link' sent to their email) on my own. I know designing security systems without experience is really bad, so I'm asking to know if my system has any obvious holes. Here's how it works:

User types their email & a unique username in JS client (SPA)
The email & username is sent to my API server (in GET/query string)
The API server consults the Users Database (see below for the design of this DB) to see if the email already exists
If it doesn't, the email is added to the Users Database along with the username (new user)
If it does, the API server ensures that the username matches the email, else responds with an error
The API Server generates a high-entropy GUID (long, random string) and stores it in the Users Database (in the same row as email & username)
The API Server emails the user with a link containing the GUID in a query string to a special '/auth/' route
The API Server stores the exact time this email was sent in the Users Database
If the link was not pressed within 30 minutes of that time, the GUID is removed from the Users Database (so the user has to login a again)
If the link was pressed within time, the API Server generates a new Session GUID, stores it in Users Database & puts in a cookie that's exchanged in all upcoming requests
(ie. every time a new request happens, the API Server ensures the Session GUID matches the one in the Users Database, indicating they're logged in)
The Session GUID is removed from the Users Database if the user decides to log out
The Session GUID is also removed every 3 days (so users have to log in every 3 days)

The Users Database has the following columns, with the username being the primary key:

| username | email | magic_link_guid | magic_link_guid_date |  session_guid | session_guid_date |

Some issues that I don't know how to fix:

A database call is made for each request, that can't be good
Handling user roles would be really difficult with this method
This seems susceptible to XSS/CRSF attacks

Again, I know rolling out my own system is bad, but I can't find a ready-made passwordless system for .NET/C# :(.

What you describe is a token authentication system. Is is not so bad, and as it has been said in comments it a the common way to implement a forgotten password feature.
Some well know applications such as redmine natively offer such an authentication system to smooth the implementation of automatic operations using an API.
One problem is the duration of the token what you call the session GUID. Here you force the user to connect at least every three days which is really intensive. If it is for professional reasons, employees are generally allowed to take holidays longer that 3 days, and for non professional task doing them every 3 days is enthusiam (from the silver badge in SE network for visiting a site for 30 consecutive days). What is a user goes for a track in mountain without network access? That means that you will have to intensively use the password generation that only relies on username+email which is not enough secure for a generalized use. But you also know that the longer the session GUID is used, the more risk of being stolen exists.
Another weakness is the handling of a permanent cookie client side to store the token. That is more or less storing a password in clear text on the client which is known to be bad. This alone should scare any security aware user. For example in redmine, the token is generated and stored in the app, and the user generated one just before using it for its API requests.
Now for your questions:

A database call is made for each request, that can't be good
No problem here. Caches are meant for mitigate that problem. Do not even try to do it by hand but just rely on a well known cache. Also as you speak of a browser client side, you can just rely on HTTP (or HTTPS) sessions once a user is authenticated

Handling user roles would be really difficult with this method
User roles shall not be handled client side. You should have a table describing the roles allowed to a user: User_ID | Role_ID. When you find a user, you search its roles and store them server side in the session. Or rely on the cache if you use a non connected API.

This seems susceptible to XSS/CRSF attacks
It may or not be a problem. But you should at least ensure that the token cookie is associated only with your own domain! And also rely on common mitigation ways on forms.

TL/DR: This is a token authentication system. It can be used as a complement of a main authentication system but do has serious weaknesses in the described implementations if used alone. In the opposite, the remaining questions are not really a problem and can be answered in the common way.


How to single key decrypt pgp encrypted mails in a multi key/multi identitiy setup? For pgp encryption I'd like to combine short expiry terms for public signing and email encryption with (convenient) long term decryption possibilities of my mailbox mails.

I'm using several mail addresses where each is used and issued only for a different group of people. For each mail address thus I have a different key-pair to expose only one address to a certain group.
In this setup encrypted mails in my inbox force me to keep all the expired keys and passwords which I find very inconvenient.

My idea was to have

a single non-publicly issued, non-expiring key-pair for mailbox purposes (re-encryption?, decryption)
several publicly issued, short expiry, independent key-pairs for several mail addresses

Which ways do exist to achieve my desired setup? Do for example master and sub-keys provide a possibility to decrypt my mailbox with a single, non-public key-pair for multiple identity independent sub-keys? If no, how do I automatically decrypt end re-encrypt mails over imap by script or mail client?

I don't believe OpenPGP has a mechanism built in to handle this situation. If your goal is to have a repository of emails, all encrypted with a single non-publicly-shared identity's key I'd suggest just creating an archives identity/keypair/email and forwarding all messages to that address yourself.

Of course, if you delete an identity's private key and later receive new messages encrypted for that identity you wont be able to read them.


Using V4 UUID for authentication I'd like to use a V4 UUID / GUID for authenticating users. To be specific, the user would have to paste the UUID into a text field to gain access to their account. The UUID would be given to them at the time of registration.
The UUID would be combined with a username (public) when authing.

Assume normal security practices are in place (SSL, DB holding the UUIDs is encrypted at rest, guards against brute force attacks, UUID would not be passed in a URL, etc). Assume that the application isn't for anything extremely important (banking) but is still fairly important (pretend it is domain names, for the sake of argument). Don't worry about the usability issues that the user might have. I'm just concerned about security.

Given the above, is this still a bad idea?
Do you think this is less secure than username / pass?
Would slamming two UUIDs together be more secure?

My goal here is to not be storing personal data of any kind (email / pass). My hope is that this is a viable alternative.

UUIDs do not generally guarantee unpredictability or any security properties.  As RFC 4122 says (section 6):

  Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.  A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator.  Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee.  The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

  The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure.  For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation.  The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing.  The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP.  For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.


How to prove the Apache web server is not accepting connections anymore because of an denial of service attack (Slowloris)? I have a network dump (PCAP file) from a "conversation" between a web server apache (192.168.1.2) and some clients:

What a should look for to prove that the server buffer (or TCP WINDOW) is full? I received 403 error (error.log). I know it was a denial of service attack (slowloris).

With .pcap file

Unfortunely, you can't ask for server status, while just looking for communication line.

But, you could count how many different connection are opened by one ip:

/usr/sbin/tcpdump -anr myfile.pcap |
    sed 's/^.*IP \([^:]*\)192.168.1.2.80:.*/\1/p;d' |
    sort |
    uniq -c

This will show a lot of

          10 192.168.1.8.36684 >
           4 192.168.1.8.39619 >
           9 192.168.1.8.39856 >
           4 192.168.1.8.39896 >
           5 192.168.1.8.40195 >
          12 192.168.1.8.40196 >
           9 192.168.1.8.52288 >
           7 192.168.1.8.58529 >
           9 192.168.1.8.58639 >
           9 192.168.1.8.58730 >
           6 192.168.1.8.58835 >
          13 192.168.1.8.58851 >
          12 192.168.1.8.58852 >
          10 192.168.1.8.58882 >

You could try to count how many connection per seconds, but how many maintened open connection is stronger.

Near real time

If  located on a proxy, a router or the server himself, you could trace real time connections with

tcpdump -ani eth0 host 192.168.1.2 and port 80 |
    sed -une '
      s/^\(.\{8\}\).* IP \(.*\)\.[0-9]\+ > 192.168.1.2.80: Flags \[S\],.*/\1 \2/p
    '

If too much output, you could count connection by sec, with a little delay due to uniq bufferisation and count

tcpdump -ani eth0 host 192.168.1.2 and port 80 |
    sed -une '
      s/^\(.\{8\}\).* IP \(.*\)\.[0-9]\+ > 192.168.1.2.80: Flags \[S\],.*/\1 \2/p
    ' |
    uniq -c

Next step

If based on Linux, you may start to play with iptables to build triggers for this kind of attacks, have a look there:

How to best defend against a “slowloris” DOS attack against an Apache web server?  @ serverfault.com


Will a switch only send data to its recipient? I have an ISP supplied cable modem/router over which I have almost no control. They can upgrade the firmware remotely, so I assume they can do virtually anything with it.

When I transfer data using the switch that is contained within the modem, I think they could look at the data. When I use my own switch which is connected to the ISP modem, will the ISP modem see the traffic that goes through the switch?

I know WiFi that is secured with WPA2-PSK can be eavesdropped upon, same as BNC-style network or those old CAT-style hubs I had in 2000. That is the source of my confusion/suspicion.

A switch will try to only send traffic to its intended recipient. But it is not guaranteed. If the switch doesn't know where the recipient is, it will send the packet to all devices connected to the switch.

There are ways to make a switch forget where the intended recipient is (such as overflowing the CAM or MAC spoofing).

There are also ways to make individual computers send packets to some other MAC than the intended recipient (ARP spoofing and the like).

You should only consider a switched network to be a trusted network if you either trust every device connected to the network or the switch has some advanced security features to protect against all the attacks described above.

You'd be better off using a router, which is controlled by yourself only. If using your own router would mean an (extra) layer of NAT, you should use a bridging firewall instead.


Why does Windows Ship with Expired SSL Certificates? I am cleaning up the certificate stores on my Windows machines, and considering which certificates I should keep, and which ones I should delete.

Why does a fresh install of Windows Server 2012 R2 come with certificates such as these:

Considering that these certificates expired back when I was in high school, what could they possibly be good for?  Why would they still be included with the operating system 15 years later?

In essence, these certificates are necessary and required for backward compatibility with XP and Server 2003. If anything was signed with these certificates, even if they're expired now, your server needs the cert trusted in order to trust the thing that the cert signed.

Source: http://support.microsoft.com/kb/293781

  Some certificates that are listed in the previous tables have expired. However, these certificates are necessary for backward compatibility. Even if there is an expired trusted root certificate, anything that was signed by using that certificate before the expiration date requires that the trusted root certificate be validated. As long as expired certificates are not revoked, they can be used to validate anything that was signed before their expiration.


Transferring credit card details to hotels without PCI I'm developing a web application for hotels that send offers to the guest's hotels. I want to store the guest's credit card data in a secure way, through a third party service as I don't want to implement a PCI DSS compliant solution myself.

I don't want (and I cannot) process the payments, as each hotel has its own payment gateway and it will process the payments later on. However we should give to each hotel the capability of accessing credit card data upon offer acceptance by guests. Hotels must perform antifraud check (like 1$ transaction) or introduce the cc data in their payment software system.

I would like to understand how this workflow could be achieved: most of the online services offer "tokenization" as a storage solution.

Which seems good, but I don't know how the send the card information to the hotels. It seems to me that tokenization is used to perform later the transaction, which I cannot do on behalf of the hotels. Moreover, once tokenized, it seems to me that data cannot be recovered. Each hotel must be able to actually see and use the cc data of its guests.

Any help and/or reference to a suitable provider is welcome.

I want to store the guest's credit card data in a secure way, through a third party service as I don't want to implement a PCI DSS compliant solution myself

Sorry, you still need to be PCI-compliant. Read the following:

Q2: To whom does the PCI DSS apply?
A: The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data.
Source: To Whom does PCI DSS apply?

That being said, you may qualify for one of the less restrictive levels of PCI-DSS.  To find out, check this link: Which SAQ is appropriate for me?
Also, depending on the hotel, you may need a lot more than just the credit card number.  Typically they will also submit name, address, expiration, and CVV in order to validate the transaction.  If they require CVV, you have a serious problem: you cannot store CVV in any form for any purpose.
Here is a good reference to get you started on your own compliance: ComplianceGuide.org.


How Concerned should I be about VM Escapes? I intend to start learning how to do malware analysis and forensics, but I have a concern or two.

I want to start by just analysing code that I write myself, and that'll be fine. But at some point I'm going to want to start analysing real malware.

As is normal, I'll be analysing within a Windows VM (on a Windows host), with something like INetSim hooked in and all that.

My concern, however, is around VM escapes. How concerned, or not, should I be about VM Escapes, if I keep my VMWare Workstation up-to-date? I've looked around the internet, but the general literature out there seems to be focused a lot on enterprise/cloud VM escapes in the sense of accessing other VMs on the same physical hardware. I'm not sure how much this could apply to a non-enterprise situation, where the concern is an attack on the host, rather than on different guests.

Is this one of those cases where the malware would need to be very specifically written to escape the VM, and if I'm doing proper research on the samples I intend to analyse then it shouldn't be a concern?

I guess the other question is that, beyond the obvious disabling external internet access (i.e. putting the VMs on host-only/internal networking) as soon as the samples are downloaded, are there any other sensible precautions I should be taking?

Thanks in advance

TL;DR version: You should not be worried about VM-escaping malware if you do things right - the likelihood of that is pretty low.

Having said that, the internal networking scenario you described (common virtual between host and guest) is not sufficient to protect against VM escapes in the form of worms. Most host services would listen on any network interface, including the internal virtual interface that is common with your guest. This means that malware with worming capabilities looking to exploit vulnerabilities over the network (e.g. the good old WannaCry-wannabe's gunning for EternalBlue, the new kids with BlueKeep, etc.) executed on your guest may be able to reach your host via the shared network.

The answer is simple: isolate the two as much as possible, with no common network interfaces between the host and guest.

In my years of digging through harmful code, malware capable of escaping VMs has been extremely rare - threat actors are frequently staging their attacks, with multiple downloadable components, so they don't burn all of their tools early in the chain. VM escapes come really late in the game, when the threat actor has ascertained that they are not on a honeypot or a forensic station, they are certain they have not been detected, and then and there they would initiate a next-stage download.

Most of the time malware would run checks if they are in a "sandboxed" environment, e.g. it will check for Internet connection, presence of virtualization, and several other criteria (such as the presence of meaningful files in the user's profile) - these are usually the tell-tale signs that the code is executed in a sterile "forensics" environment, and the code will simply not run. So completely cutting the Internet may also not be feasible.

It's best that you do your experiments in a completely segregated environment, but that's not always feasible, especially for the novice - the investment may be substantial.

Hope this helps!


Securing REST API via Hawk I'm currently using Hawk as the auth scheme for an API. Basically, the current flow (forced SSL) involves:

User types in email/passwd on app
App performs 1000 rounds of PBKDF2 using the email as salt, sends the result along with the email for registration
Server hashes the password using scrypt (64k/8/1) and a random 32-byte salt and stores the salted password in the user account
Server creates a hawk shared secret and sends it back (id and shared secret) so the client can create the appropriate header payload if the password is correct.

However, reading this discussion regarding the implementation, something came up:

  I can't think of a problem with that but being that it's creative, security folks don't like it. The main issue is that you created a new pattern that is not as well understood as the normal flows. You should think/implement this as two system. One that takes a username/password and returns a token (be it a cookie or rsvp), and another that takes that token and gets new credentials with it, bound to whoever is using it. Your solution cuts corners a bit which is fine if you don't have a public API or multiple apps.

link

Sorry if it's too noobish, but how's adding another layer (a level of indirection, as I see this) any more beneficial?

Looking at hawk implementations in production, eg: Mozilla's onepw protocol I noticed they return a session token which is then derived using HKDF to compose the hawk credentials.

I wouldn't say there is anything wrong with your approach. Security people are just really into always using the accepted methodology. Take CSRF mitigation for example. There's a bunch of ways that successfully mitigate CSRF but security folks always recommend using a CSRF token because that's the accepted standard for mitigating CSRF attacks. I think the main benefit for separating the transaction into two steps is that the transaction is easier to reason about because each step of the transaction has a specific goal. Yours combines some steps but I don't see any reason why that is necessarily bad, just a little more complicated.


Google Analytics on a secured site Just read this article on Google Analytics and the risk of forged certificates, where it said:

  Sooner or later it's going to happen; obtaining forged SSL certificates is just too easy to hope otherwise. What can we do about it? Don't load the Google Analytics javascript when your site is accessed via HTTPS. This is easy to do: Just throw a if("http:" == document.location.protocol) around the document.write or s.parentNode.insertBefore code which loads the Google Analytics javascript. On the website for my Tarsnap online backup service I've been doing this for years — not just out of concern for the possibility of forged SSL certificates, but also because I don't want Google to be able to steal my users' passwords either!

The thing is, one of the best things about Google Analytics is the ability to track goals -- getting users to interact with the site in specific ways.

If I turn off this functionality for SSL, it means that many of the goals -- getting them to sign up and getting them to buy things -- are going to necessarily be blocked.

So, I'm torn. Is there any way to continue using Google Analytics for this purpose while maintaining some semblance of security for my website? Is it just an impossible tradeoff of functionality vs. security?

Essentially yes it is risk. If you choose to use a third party hosted JavaScript (one example is Google Analytics) in a secure page you open the door for information to be collected. That may involve a maliciously forged certificates or simply a change in the ga.js script by Google.

You could consider the flow of you web application to try and push people through sections that don’t require security to capture analytic data, alternatively you could consider a Google Analytics for Mobile devices implementation.

Devices that do not support JavaScript would not normally be able send analytic data to Google. In this case Google provide alternative server-side implementation samples. See http://code.google.com/apis/analytics/docs/mobile/mobileWebsites.html

In this case if you have access to change the code or extend your web application you could send only the information you want to Google. This will obviously require you server to initiate a connection to Google which may induce load and should be carefully secured.

This design was not the intended for web clients that support JavaScript so you should verify that it does not violate Google’s service terms.


How to configure iptables for must open ports? On my machine there are web services which can be accessed from any PC connected to the same network segment (WiFi for example). I want to use IPtables on the machine to prevent any web services from being accessed by hosts on the Internet at large.

What rules should I configure IPtables with?
How can I protect a port which is always open?

Set the default policy to deny everything. (iptables -P INPUT DENY)
Allow ICMP
Add the minimum rulesets required for the services you need.

If you've got ports that are used only by local machines, set allow rules for that combination of port and IP range only.

iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT

Outbound traffic needs rules as well (permit DNS queries, permit services to respond to connections, etc). Using related / established rules can help with this. Even among otherwise locked-down firewalls, allowing all outbound traffic for simplicity is common.

If you've got the time, an ideal albeit laborious case would be using SELinux to restrict things even further such as by only allowing the DNS resolver libraries to query DNS, etc.

As for "protecting an open port" that comes down to configuring the software listening to it correctly and ensuring any security issues within it are addressed.


Safe to download router firmware over unencrypted HTTP? I went to download the latest firmware for my router and noticed the download link is not HTTPS, so I sent the following email to the manufacturer:

  I went to look for new firmware for my Archer C7 router, but I saw
  that the download link is over unencrypted HTTP, not secure HTTPS. I
  would never download software or firmware over an unsecure connection.
  Please upgrade your site to HTTPS.

This was their reply:

  The device will verify the integrity and correctness of the bin file,
  if it is tampered, it won't be able to upgrade successfully. Don't
  worry, you can download it.

Ignoring the fact that they have no excuse for not using HTTPS, my question is: Is it even possible for the router to confirm that a new firmware file hasn't been tampered with? How would that work?

Sure - it could be a signed image. If the router has a built-in public key, and the image was signed by the corresponding private key, it would be perfectly safe.

Unless someone had got the private key, and uploaded a malicious version to the server, in which case, HTTPS wouldn't help either.


SMS / voice call interception with a fake base station This answer to a similar topic describes in a detailed way how vulnerable SMS and voice calls are in terms of decryption. In order to do so, an attacker needs to set up a fake base station located relatively close to the victim's device.

Assuming this scenario, I have the following questions:

Is the attacker able to intercept only traffic FROM the mobile phone or also TO the mobile phone? I would imagine that a carrier does not forward SMS or voice calls intended for the victim's device to a fake base station as he knows which base stations belong to his network, isn't it?
How does the integration of the fake base station into acarrier's network work? I'd assume that there has to be some sort of authentication?

This video demonstrates the fake base station attack.

To answer your first question, yes, it does go both ways (I'm pretty sure) (see edit and comment below).  The device is in the best place to determine the most efficient communication path (that is, the nearest base station); therefore, it makes sense that the network would use the cell phone's nearest station to send communications on. (see edit below)

The fake station can communicate with another real station to complete the network connection (to be over the top, you could also make your own satellite link).  It does make sense that stations would have to be authenticated, but this is apparently not the case (see video).  It seems that the fake base station actually integrates pretty seamlessly.

Edit: According to the comment below, intercepting an inbound call is actually more difficult for cryptographic reasons.  My guess is that the real base station gets to determine the encryption in this case, not the fake one (don't quote me on this).


How would iOS or Android app "firewall" for extended permissions (location, etc) work? I'm interested in blocking or reporting any application's usage of extended permissions, regardless if they are granted those rights, such as:

GPS / Location / Wifi
Radio signal data
Telemetry

My rational is related to a person's privacy.  For example  Facebook Messenger has an application-level icon to disable location reporting.  How can I theoretically force the app to no longer use that feature at an OS level?  (yes, Settings will do it, but where in the OS stack does it operate?)

The answer I'm interested in will refer to iOS and Android Operating System details, and not a simple security on/off switch available in Settings.

Example answer

Taking the Windows OS as an example, most of this would be handled in the Kernel, and within that, a protected subsystem that probably doesn't operate in privileged ring 0.  Interesting API's would be located in XXX library (kernel.dll?)

What layer in the Android and iOS operating system is most suited to blocking or controlling permission access at runtime?

I can only speak for Android, I have no idea of iOS.

Granting permissions is (mostly) handled in the framework, while the Linux kernel and appropriate Linux-Users and Linux-Groups for each app ensure that the framework is not circumvented. Interesting internal APIs are mostly located in /frameworks/base within a regular Android source tree

In Android, the framework will take care of filtering requests on runtime, based on the permission model. The process is roughly as follows:

If an app uses the API to perform some protected operation (such as reading your current GPS location) the handler (in this case, the LocationManagerService) will check if the required permission has been available to the calling context (roughly: the app's manifest, which has been confirmed by the user while installing). If so, it will perform the action requested; if not, a SecurityException is thrown. Regular Linux kernel mechanics prevent apps from accessing ressources without using the suitable API (excluding, of course, apps running as root on a rooted device).

You can find a general overview article on the Android security features at the official documentation homepage. It is, however, not tied to permissions.


How does sound signature recognition work and how to override it? Today a lot of websites that allow the upload of media content are implementing automatic sound signature checks to prevent the illegal distribution of videos containing copyrighted content.

How does the sound recognition system work?
How could such an algorithm be tricked?
Could the sound be altered enough to change the sound signature without significantly changing the human experience of the sound?

The recognition software is just comparing hashes/fingerprints...

see: http://en.wikipedia.org/wiki/Acoustic_fingerprint  &
http://en.wikipedia.org/wiki/Hash_function
also might be of interest: https://stackoverflow.com/questions/2068286/music-recognition-and-signal-processing

and yes, you can get fake out many of those platforms (for whatever your perfectly legal purpose is) One possibility is detailed here: http://www.turkeymonkey.com/2009/07/19/how-to-get-around-that-pesky-copyrighted-audio-filter-on-youtube-and-facebook/


Isn't ssh-copy-id exposing to a brute force attack? It is a common knowledge, that using keys to authenticate ssh users is more secure than using passwords. However, even with password login disabled, when running ssh-copy-id I am still asked for user's password. It makes me think - what stops the attacker from trying to brute force this password instead (and upload self-generated public key to gain permanent access)? Is it a security hole, or am I missing something important?

P.S. let's assume there is no fail2ban or similar software running

ssh-copy-id is a script that simply logs onto a target machine and copies your public key there, so that further login attempts on that machine can be done with your SSH private key. This assumes that you can log on that machine right now, while your public key is not there. If you get asked for a password, then this means that password-based login is still enabled on that server (or at least that the client is trying to authenticate with a password, which may or may not work depending on server configuration).


Tab under behaviour blocking I have recently been reading about scenarios where browser might block automatic redirects. One scenario that i came across is what chrome calls as "tab-under". When the user clicks on a link to open in a new tab, the original tab redirects to an advertisement. To block this, chrome shows a redirect blocked banner.
I understand why chrome would want to do this, but i don't understand the reason why sites would want to implement this behaviour specifically?

can the site not auto redirect the main page to the advertisement in some time without the need for user clicking on the link or opening the new tab? . It is their website, I don't think the browser would block this redirection or this change in window.location.

can the site not open the advertisement in the new tab automatically? - I assume the popup blocker would block if they opened a new window automatically

can the site not open the advertisement in the new tab instead of opening the content in the new tab and opening the advertisement in the main page? This would give the advertisement a better chance of being seen

can the site not auto redirect the main page to the advertisement in some time without the need for user clicking on the link or opening the new tab?

They lose your focus. You got redirected to the ad site, you probably will not get back. If you got interested, you will interact with the target site, not theirs. If you aren't interested, you close the tab.

can the site not open the advertisement in the new tab automatically?

They can open a new tab and not be blocked only in a short time frame after loading the page, or when you interact with the site. That's why some sites that opens a popup have a link saying Click here to open, so if your browser blocked the automatic popup, the link will open it.

can the site not open the advertisement in the new tab instead of opening the content in the new tab and opening the advertisement in the main page?

They aren't interested on the ad being seem. No matter if you saw it ow not, they are getting paid anyway. Opening their site on a new tab makes the history clean, and you probably will close the ad on the original tab, and lose the track of the sites you went until reaching theirs.


Do NOP sleds expose shellcode? I noticed the following sentence on Wikipedia.

  Since intrusion detection can detect signatures of simple shellcodes being sent over the network, it is often encoded, made self-decrypting or polymorphic to avoid detection.

Encoders can camouflage shellcode. However, payloads are often delivered with leading and/or trailing NOP sleds. Could an IDS not simply scan for NOP sleds to detect shellcode?

IDSs will look for nop sleds, but they can also be masked.  Consider that any instruction that is:

Valid and executable
Will continue execution somewhere in the nop sled between itself and the payload
Doesn't affect any critical registers (stack pointer)

Is valid for our purpose.  As long as any sequence of instructions in the sled is a valid starting point (which will end up at our payload), we will have an error-free sled.  If we are okay with it not being 100%, we can be even more creative with our sled.

Check out the nop generators available for metasploit for some ideas on how you can make it, at the very least, expensive for IDS to detect sleds.


Why are chips safer than magnetic stripes? After the recent Target hack there has been talk about moving from credit cards with magnetic stripes to cards with a chip.

In what ways are chips safer than stripes?

You can't clone the chip.

A magnetic strip holds a secret number, and if someone knows that number they can claim to be the owner of the card. But if a bad guy swipes the card, they then know the number, and can make their own card, i.e. "cloning". This has turned out to be a major practical problem with magstripe cards.

A chip also holds a secret number. However, it is securely embedded in the chip. When you use the card, the chip performs a public key operation that proves it knows this secret number. However, it never reveals that secret number. If you put a chipped card in a bad guys machine, they can impersonate you for that one transaction, but they cannot impersonate you in the future.

All of the above assumes that the implementation of the chip is good. Some chips have been known to have implementation flaws that leak the secret code. However, chip and pin is now pretty mature, so I expect most of these issues have been ironed out.


RFC 6455: Form fields with starting |Sec-| mean? In RFC 6455 which is the Websocket Protocol specification it says:

  It is similarly intended to fail to establish a connection when data
  from other protocols, especially HTTP, is sent to a WebSocket server,
  for example, as might happen if an HTML "form" were submitted to a
  WebSocket server.  This is primarily achieved by requiring that the
  server prove that it read the handshake, which it can only do if the
  handshake contains the appropriate parts, which can only be sent by a
  WebSocket client.  In particular, at the time of writing of this
  specification, fields starting with |Sec-| cannot be set by an
  attacker from a web browser using only HTML and JavaScript APIs such
  as XMLHttpRequest [XMLHttpRequest].

I know HTML forms but, why server and client communicate with HTML forms? And what are |Sec-| fields? I'm not a web technologies professional but, I know HTML forms can be easily manipulated with HTML and Javascript APIs.

Sorry if it is too basic to ask, tell me that and I will go read relevant tutorials.

As mentioned in comments section, quoted part from RFC 6455 standard under Security Model section discuss about possible code injection attacks and it's usage WebSockets as a attack vector.

For possible attack scenarios RFC 6455 specifies mitigation techniques with properly defined handshake policy. Theoretically attackers wouldn't get required interface for establishing proper connection.

Sec-* headers required for establishing and maintaining connection and mentioned mostly at fourth section Opening Handshake. They are:

Sec-WebSocket-Key
Sec-WebSocket-Extensions
Sec-WebSocket-Accept
Sec-WebSocket-Protocol
Sec-WebSocket-Version


How do I know if a website encrypts passwords apart from SSL? I manage a team of developers and only recently found out that passwords are not hashed at database level. We were trying to get PCI approved and the inspector informed me on the hush level that CC and Passwords are being stored by developers without hashes.

This made me concerned. Firstly, users automatically assume that SSL means their data is encrypted. This is not true since CC and Password information on our databases are stored in plain text (we have since removed this and have installed SALT on all data)

Is there a way for me on a website to see server side or find out if passwords and CC are actually encrypted.

No, you can't be sure that a site has correctly hashed your password.

However, there can be some signs that they did not, particularly if they e-mail your existing password as part of the "forgot password" functionality.


Does End of Life Hardware comply with PCI DSS 3.2 if still under support from a Third-Party, Not the actual vendor? Can some one help me to confirm that End of Life hardware complies with PCI DSS 3.2 or not?

I only see requirements for software but no mention of hardware? Any guidance would be greatly appreciated.

  6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security
  patches. Install critical security patches within one month of
  release.

I worked for a PCI ASV for five years. This isn't compliant - you can't ensure that you're patched against security vulnerabilities if there are no security patches to apply.

However, your PCI ASV may, at their own discretion, choose not to fail you for it. I have seen clients in situations where changing the software would cost multiple millions, or where there's literally no other option. The way this is usually resolved is that they apply secondary security controls to mitigate the risk, for example isolating a Windows application inside a well-configured Citrix XenApp instance on a terminal services server, with AV installed (and up to date!) and OS lockdown in place. Or, for a web application, installing a WAF and making custom WAF rules to prevent exploitation of known vulnerabilities (e.g. XSS) as and when they come to light. In all cases this involves an in-depth security assessment of the EoL'd product in order to ascertain its security posture and risk. In most cases it also involves providing your ASV with a long-term plan to replace or move away from the EoL'd product.

Your ASV absolutely must mark non-compliant components of your network or system as non-compliant, but they may also mark it as an exception (with justification) and give you an overall pass on the assessment.


Are there any mechanisms in TLS 1.2 protocol against timing attacks? Are there any mechanisms in the TLS 1.2 protocol (not implementation) against timing attacks? For example, that the handshake response time should be padded to X milliseconds? Or should I implement such mechanisms manually ?

Yes.  See the RFC for TLS 1.2 (RFC5246) and note the MUST.

   Implementation note: Canvel et al. [CBCTIME] have demonstrated a
   timing attack on CBC padding based on the time required to compute
   the MAC.  In order to defend against this attack, implementations
   MUST ensure that record processing time is essentially the same
   whether or not the padding is correct.  In general, the best way to
   do this is to compute the MAC even if the padding is incorrect, and
   only then reject the packet.  For instance, if the pad appears to be
   incorrect, the implementation might assume a zero-length pad and then
   compute the MAC.  This leaves a small timing channel, since MAC
   performance depends to some extent on the size of the data fragment,
   but it is not believed to be large enough to be exploitable, due to
   the large block size of existing MACs and the small size of the
   timing signal.


Is my credit card information "wide open to hackers" without VPN? I saw an ad for a vpn provider recently where they claimed that, without using a vpn, my credit card information is "wide open to hackers" while shopping on-line. I guess the implication here was that vpns are encrypted, while regular connections are not. However, isn't https encrypted, and therefore safe to use without vpn? And aren't on-line stores required to use https or other forms of secure payment?

It depends.

If you enter your credit card information on a site which is not protected by HTTPS then a VPN will provide at least part of the missing protection, like addressing the problem of an attacker in the local WiFi hotspot.

If you enter your credit card information on a site which does not properly handle this information neither a VPN nor HTTPS will not protect you. This might be cases where the site accidentally puts this information online by itself or where it got attacked and the data exfiltrated.

Similar if you enter your credit card information on a site which is already compromised the attacker might grab the information right where you enter these. A VPN will not protect you against this and neither does HTTPS.


How paranoid should the average user be about heartbleed? Questions about Heartbleed have been showing up in the popular questions list today since morning, from the security stack exchange to android
I have been reading many of them, most of them are technical and from a server administrators perspective so difficult to understand for the average user
These are a few simple ones that I have found

https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it
How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
What should end-users do about Heartbleed?
Does the heartbleed vulnerability affect clients as severely?

I do not understand the technical details, so as an average windows user, how paranoid should I be, and is there anything that I should (or can) do, if a service that I use is vulnerable?

For example, the accepted answer for item 4 above says this about vulnerable systems:

  Information on common clients:

  Windows (all versions): Probably unaffected (uses SChannel/SSPI), but
  attention should be paid to the TLS implementations in individual
  applications. For example, Cygwin users should update their OpenSSL
  packages.

  OSX and iOS (all versions): Probably unaffected. SANS implies it may
  be vulnerable by saying "OS X Mavericks has NO PATCH available", but
  others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not
  affected. Apple says: "OpenSSL libraries in OS X are deprecated, and
  OpenSSL has never been provided as part of iOS"

  Chrome (all platforms except Android): Probably unaffected (uses NSS)

  Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2
  should be unaffected, as it is compiled with heartbeats disabled.
  Source. Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey,
  Fennec): Probably unaffected, all use NSS

So if I am an average Windows user with chrome as default browser, I am not vulnerable? I don't think that's true so I am probably not getting something here. This page says that Yahoo is the biggest web service provider that is known to be vulnerable (also includes stackexchange). So if I have a Yahoo email or stackexchange account, does this mean my password is vulnerable from my computer's side when I type it in? In the answer that I quoted above, it says Windows and Chrome are probably unaffected as they don't use openssl. So how does this make me vulnerable when using Yahoo and stackexchange that apparently do use openssl? Is there anything I can do about it, and if so, what can I do? Change my password immediately, or wait for them to contact me, and change password after that?

I have another question. The accepted answer for item 1 has this to say:

  Well, errant code in OpenSSL. Here is the commit that fixed the
  vulnerability. I won't speculate on whether this was truly a mistake
  or possibly a bit of code slipped in on behalf of a bad actor. The bug
  showed up in December of 2011 and was patched today, April 7th, 2014.

If the bug is that old, and it really is this serious, then why wasn't anything done till now?

Your system isn't vulnerable to the issue as you're on Windows browsing with Chrome, but a majority of the sites you visit and use were quite possibly vulnerable.

There are several things you can do:

Check the SSL certificates of websites you visit, make sure they have been issued after 7th April 2014
Verify the websites you visit have been patched or aren't vulnerable (This might help: http://filippo.io/Heartbleed/)
If they aren't vulnerable and the certificate is post-Heartbleed, then change your password (in case it was compromised)

Personally I have a Firefox addon called "Certificate Patrol", that alerts me when a certificate has been replaced or is new, which helps remind me to check to see if they're safe or not. I also have addons that identify the software running on servers, so I know if they're running a server that wasn't affected by Heartbleed (Windows Server for example, or OpenSSL 0.9.8)

  If the bug is that old, and it really is this serious, then why wasn't
  anything done till now?

Nothing was done until now because nobody knew there was a problem until now. Unfortunately it slipped in without getting noticed - In projects that are large and have a lot of contributors, mistakes happen. It is unfortunate that it went so long without being noticed and fixed though.


Do I need high password security if I also require a Client Certificate for validation? Due to an ongoing discussion in my office, I was wondering if anyone had any comments on whether password hashing security needs to be very strong if client certificate validation is also required for account verification.

We use SHA-512 hashing with a randomized salt for password storage. It has been suggested that we don't need to iterate the hash function as we require BOTH password and a client certificate for user validation.

Is our account security significantly lower if we reduce the number of hash iterations taking into account we also require client certificate validation?

Since in some some cases we allow certificate-only validation, and in SOME cases (i.e. on developer machines) we allow password-only validation, I'm tempted to suggest that we allow a low number of iterations (or no extra iterations) of the hashing method for users that require client certificate validation, but require a normal number of hash iterations for users that don't. Does that make sense?

You do need a proper password hash (slow and salted — iterating is one way to make it slow). It doesn't matter that the user has a second authentication factor such as a certificate. Hashing the password doesn't protect against the same threat.

Using a second authentication factor protects against someone guessing the user's password on your site, or obtaining the password by snooping on communication, by shoulder surfing, with a keylogger, etc. The protected asset is access to the user's account. For that purpose, the way your server stores the password is irrelevant.

A proper password hash protects the password against an attacker who gets access to the password database on your server (or a backup). The protected asset is the password value, which the user may have used on other sites. For that purpose, how the user authenticates on your site is irrelevant. Your server could even store a password hash that it doesn't use to authenticate the user (for example, if you're running a proxy authentication service), and it would still need to store the password securely.


What is the most appropriate way to notify/request permission from an ISP related to white-hat security testing? In some of the posts I've read on this site such as Is hacking legal when a friend allows you to attempt to hack their system?, and Best way to test my home network from the outside, users who responded pointed out that testers should notify or request permission from their ISP to do testing. I have difficulty imagining such requests would go over very well with an ISP. It seems they have everything to lose (from a liability point of view), and little to nothing to gain, from approving your request to perform penetration testing over their network.

Has anybody successfully asked an ISP for permission to do security related testing over their network? How would one do so?

I have never asked for permission in advance (that I can recall), but I can say clients on many occasions have reported IP addresses under my control to be attacking them.
For example:

TOS Violation - Malicious Activity
We have received a report of malicious activity originating from an IP address assigned to (redacted). Please investigate this complaint and update this ticket within 24 hours to avoid a disruption in service.

Most often my clients simply neglected to check the list of authorized IP addresses I mentioned I may use during testing.
On every occasion, after answering a TOS violation, the ISP goes to verify with the target that the activity is authorized and all is good.
Note:  Amazon now makes it easy to ask for permission in advance:  http://aws.amazon.com/security/penetration-testing/ (I have heard others do as well now)


Purpose and Uses of Root SSL Certificates I'm trying to wrap my head around the technical inner-workings of SSL and one of the last things I'm choking with is the concept of "root" SSL certificates (as opposed to "non-root"?!?).

When and how would an organization attempt to get a root cert as opposed to just a normal cert?
What are the benefits to using a root cert?
What are the use cases or application for a root cert?

I guess these questions are similar and are just different forms of why would I ever need a root SSL certificate, where would I get it from, and what would I do with it?

Thanks in advance.

A root SSL certificate is one that is used by a certification authority to sign other certificates -- either end-user certificates or chain certificates that are then used to sign end-user certificates. Their use case is to be distributed to users by secure channels so that they can be safely used to validate other certificates. For example, dozens of root certificates from certification authorities are included in all web browsers.

If you want one of your own, you can create it using openssl. You would then use it to set up your own certification authority, but since your root wouldn't be included in the user's web browser, you'd have to create some other secure delivery channel for it.


How do gift card scams work? A common scam is that the victim is contacted by someone claiming to be from  the tax office or whatever, and that the victim is required to pay a fine.

The victim then buys gift cards and gives the codes to the scammer.

My question is - how does this actually end up earning the scammer money?

I can understand how it would work if the gift card can be used to buy physical items, as the scammer can then conduct a second layer of the scam where they sell the physical items on Ebay or similar.

But for something like where the gift card is something like an ITunes voucher, surely Apple would just reverse the charge and invalidate the the gift card? Or does the scam rely on this not being possible?

Of course, the scammer could be selling ITunes vouchers online directly, but if those were getting cancelled - then surely they would never find a buyer.

The important thing to remember is that, in essence, scammers are operating on their home turf. They get to dictate the payment method, and as a result a (good) scammer will make sure and use a "payment method" that meets the following two criteria:

The transaction cannot be reversed
The payment can easily be converted to cash or used directly

Note that the above criteria are why Western Union is so common in scams: once you send the money you can't ask Western Union for a refund a week later, and on the other end the scammer can receive cash directly. Gift certificates have the same advantages:

You generally can't cancel the purchase of a gift certificate
A scammer can use a gift certificate to buy stolen goods for sale, can sell the gift certificate directly, or even just use it to purchase things they needed anyway (h/t MechMK1)

It's possible that some kinds of gift certificates may be cancelable. It is safe to assume that the scammer knows about the exceptions and avoids them. After all this is how they make money, and in a properly executed scam the victim is going to follow orders. Therefore the scammer will choose whatever is most convenient for them.

It's also important to keep in mind that a scammer may be working more than one "angle" at the same time. For instance a scammer who gains access to a bank account doesn't just send the money to themselves. Instead they may transfer the money to another victim who sends the money to the scammer via Western Union/gift certificates. This way when the bank rolls back the bank transfer (because bank transfers are reversible), someone else is left holding the bag. Similarly a gift certificate may be sold/used quickly or exchanged for cash with another victim and as a result the scammer doesn't care if it is cancelled.

Still, if I were a betting man I would just assume that the scammer has requested payment via non-refundable methods.


Android auto complete and passwords I have an Android phone and when I enter a password in a password field (bank application or other), the auto complete system proposes to complete the password.

I expected password not to be saved by the auto complete system. I think that's a crazy security issue.

Is it the expected behavior here? Is it possible to clear the auto complete data?

Device manufacturers make changes to the original Android OS(in some cases, to a large extent). I guess your manufacturer introduced this "feature" to help you auto-complete your passwords.

Or maybe they simply forgot to check for the password field and are simply storing each string in their database.

It is definitely not desirable to have your passwords stored. You should check, if feasible, another model from the same manufacturer, preferably with the same firmware, if it exhibits the same behavior.

It is usually possible to clear the auto-complete data. Go to Settings>Apps>Keyboard, and hit the Clear Data button, it should do the trick.

You can also switch to some another keyboard from Play Store. It would be wise to download it from some reputable vendor.

Also, check for firmware updates in your device. Chances are this issue might have been reported, and they might have fixed in the next firmware.


Sec-WebSocket-Key Header Can anyone explain me which attacks the Sec-WebSocket-Key in the WebSocket handshake addresses?

I don't understand it in the RFC, neither on google.

The Wikipedia description (https://en.m.wikipedia.org/wiki/WebSocket) of the protocol seems to sum it up best.

To quote:

  In addition to Upgrade headers, the client sends a Sec-WebSocket-Key header containing base64-encoded random bytes, and the server replies with a hash of the key in the Sec-WebSocket-Accept header. This is intended to prevent a caching proxy from re-sending a previous WebSocket conversation,[25] and does not provide any authentication, privacy or integrity. The hashing function appends the fixed string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (a GUID) to the value from Sec-WebSocket-Key header (which is not decoded from base64), applies the SHA-1 hashing function, and encodes the result using base64.

Edit: removed statement regarding replay protections thanks to Steffen


Bypassing  XSS filter <img class="avatar" src="MY INPUT SPACE">

I am trying to bypass an XSS filter but it is not working since given <, > are filtered. I feel like it I could break it since only these two characters are filtered but I just couldn't find a way to do it, any suggestion on this?

The general advice (to inject an event handler in the image tag) from @MarkBuffalo in the comment is correct, but onload isn't a great choice of event handler for images. The better option is usually onerror, which is very easy to reliably trigger; just set the source to be something you know won't exist (or at least won't be an image), like src="qq" onerror="alert('XSS!')".

The specific exception I like is SVG tags, where <svg onload="…" /> is a nice short string (as short as <script>…</script>, and usable in places that try stupid tricks like filtering <script>).


security of PKI, Certificates, certificate authorities, forward secrecy I want to understand how certificates add to the security of information exchange.

Suppose i have a encrypted bidirectional connection between Alice and Bob, using a public key/private key pair. As long as i confirm by secure channels that the public key actually belongs to the expected end of the tunnel, i have secured the connection from MITM.

What security do certificates bring to the table? In theory i need a certificate from a CA itself in order to be sure that further certificates from this CA are from actually the same CA

Another doubt; its stated also that SSL/TLS supports perfect forward secrecy because IKE happens at regular intervals; i don't understand how this allows perfect forward secrecy at all; it seems that if you save all the packet exchange between two endpoints and you happen to brute-force a send-receive key, this will expose all IKE happening during that session. Probably this could be alleviated by doing IKE over several sessions, that is, exchanging each key under multiple session keys, which means you need to crack more than one key to get to other keys

EDIT i've added a follow up question here.

Yes, MITM attacks are thwarted if you can make sure that you use the right public key. Certificates are a public key distribution method which allows precisely that.

The point of the certificates is that you just need to "know" the CA public key in order to be able to verify all certificates that the CA has issued -- there can be millions of those, and it also works on the certificates that the CA will issue next week. So while certificates do not totally remove the need for a source of trust (an a priori known public key), they sufficiently concentrate that need so that the practical problem of key distribution is solved.

Gaining confidence in a public key can be done through other schemes than certificates; for instance, SSH does it by caching (you trust the server public key because you can verify that it is the same key than the last time you contacted it; in a way, SSH realizes timewise trust concentration, whereas certificates do it spacewise).

Perfect Forward Secrecy is achieved with SSL when you use the 'DHE' suites -- for "Diffie-Hellman Ephemeral". The important word here is "Ephemeral": the actual private keys which protect the session symmetric key are dynamically generated, and never stored (these are Diffie-Hellman keys); therefore, those keys are supposed to be immune to disclosure. The keys which are stored (e.g. in a private key file) are used only for signatures, so stealing them does not give the ability to decrypt past conversations (it gives the ability to impersonate the server for ulterior conversations, though). PFS is not about actual key breaks, but about key stealing, which is, in practice, a much more plausible attack path. The DHE cipher suites ensure PFS by never storing the key exchange private keys.


How reliable is a password strength checker? I've tested the tool from Microsoft available here which tests password strength and rates them. For a password such as "i am going to have lunch tonight", the tool rates it's strength as "BEST" and for a password such as "th1$.v4l" it rates it as "Medium".

I'm wondering how important password length really is. In this case the first password is better according the their tool but is it really better? It's based on dictionary words and has no combination of numbers and other characters besides spaces, and seems very easy to crack (not considering brute force).

Is that tool giving precedence to length instead of actual strength ?

"Not considering brute force" - that's exactly what these tools measure.
Obviously they dont try social engineering, or trying to discover if it's the user's first girlfriend's dog's birthday. The attacker might know that, but these tools don't.

What they do measure is simply the difficulty for a bruteforcing tool to crack it. Not even the entropy of the password, which is an attribute of the generation method, just an estimate of how long it would take a bruteforcing tool to successfully find the correct password.
Obviously, entropy has an effect on this, but it is only total entropy that matters, not entropy-per-character. So yes, having a lot of equi-probable options for each character does add to the entropy, but length can play an even more important part in making a password uncrackable, by raising the entropy-per-character to a higher power, by character count. This makes for a much higher total entropy, which is the only thing that matters.

So, in your case - yes, the 32-character, alpha-only passphrase is much stronger than the 8-character punctuation password.

I'm gonna try and do the maths here for a bit: (please correct me when I'm wrong):

If we assume standard US-style keyboard, there are 85 possible printable characters (possibly be able to scrape a few more, but lets go with this for now): lowercase letters + upper case letters + numerals + standard punctuation + space.
This grants ~6.3 bits strength per character; at 8 chars length the password gives you ~50.4 bits strength.
Note really very strong... Even if we throw in a few more "special" characters, you're not going to upgrade that very much.

Now, for your 32 character, alpha-only passphrase...
Let's assume lowercase and uppercase letters only (even though you didnt use any), plus a space (U+32). Not even numerals...
That gives you 54 possible characters, around ~5.8 bits per character. At 32 chars long, thats over 185 bits strength. Substantially stronger. And that's even without numerals, which are usually accepted even in "simple" password schemes.

Bruce Schneier often talks about how switching to long memorable passphrases would be much more secure than short, randomized weird-looking passwords.
Now you see why.


How does t-mobile's secureauthentication Twitter app work? If you try to get support from T-Mobile using Twitter, they'll try to get you to allow an app that only has permission to view your tweets and your followers. How does this help T-Mobile authenticate you?

tmobile.secureauthentication.com

This application will be able to:
Read Tweets from your timeline.
See who you follow.

Will not be able to:
Follow new people.
Update your profile.
Post Tweets for you.
Access your direct messages.
See your Twitter password.

This is the standard OAuth flow that third-party applications use to allow Twitter accounts to log into their site, and optionally have write access to the account, though in this case T-Mobile hasn't requested this permission as they have no good reason to.

What T-Mobile is most likely doing is that they use this to make sure you are the owner of the Twitter account (as opposed to just sending a link via direct messages which can be seen by anyone if it accidentally leaks) and finally associate the Twitter account with your T-Mobile user model in their CRM system.


How exactly do "hidden" processes work How can a process be hidden inside another one?

Is the process moved into another process and turned into a thread with it's own run loop?

How exactly does a process get moved? I see this Metasploit command, migrate PID which seems to do this.

I would like to know how this works internally, does it use IPC or if the memory of the process is being moved into a target process with PID, how is this done and how does the process being migrated continue to run?

Is the process moved into another process and turned into a thread with it's own run loop?

Essentially Yes.


Native rsync protocol security Is the native rsync protocol (port 873) secure? Does it encrypt data or credentials?

I'm planning on using rsync to store encrypted files in the cloud, I'm wondering whatever the password is transferred in clear.

The native rsync protocol does not encrypt anything. It is meant only for trusted networks.

To use rsync in a secure way, use it with SSH (see the "-e" command-line option) or over a VPN.


How did DNSChanger rogue name servers work? I know DNS changer, changes DNS server with its own Evil DNS server on an infected computer, then the DNS servers point to their own rogue nameservers and the nameservers change the ads on websites with their own ads. My question is that how the nameservers did it? Did they work as some kind of proxy which intercepted the flow of data, something like ettercap filters? Any links for more study would be appreciated. Thanks.

The DNSChanger trojan had all the sophistication right in the name: it would simply change the DNS server entries on the victims' computers to point to their own rogue DNS servers.

The rogue DNS servers were probably a regular BIND installation providing recursive lookups that was authoritative for zones they found interesting: other advertisers, anti-virus update sites, etc.


How does a brute force attack actually determine it has succeeded? Possible Duplicate:
  If someone breaks encryption, how do they know they're successful?

First off, this is not about cracking hashed passwords.  I know that a brute-force or dictionary attack knows it cracked the password when it gets in.

However, if an attacker is trying to brute force a message, let's say a message transmitted by a government to its embassy in a foreign country, how does the cracker determine it has finally found the plain-text?

Edited:

As it turns out, my original question was badly written.  I stated I wasn't asking about cracking passwords, and then I worded the question as if that were what I was asking, at least partly.  For one thing, I talked about MD5, which is a HASHING algorithm, not an algorithm used to encrypt for the purpose of being decrypted.  @lucas-kauffman gave a good answer to what I appeared to be asking, and thanks for that, as it was informative nevertheless.

Let me cast this differently to avoid confusion.

Given a cipher-text which was created using public key cryptography, and assuming that an attacker had the resources to use a brute force method to attack it, how would the cracking program decide whether or not it had finally achieved the plain-text?  This isn't password-cracking, where the result would be obvious (entrance gained to the thing being attacked).  Say that the message's ciphertext was something along the line of "JPOAISUDF89L;JKQWERTYQIOP34JUU890JEROTUQ3-49TJ" (<== just some random characters I typed don't try to "break" it).  How would the cracking program decide that it had found the plaintext, given that it didn't know what it was looking for in the first place?

I know a human could look at a trial decryption (presuming such a thing exists) and know that "Attack at midnight" represents an actual message, while "aroOFPS toj34ioA diy66b234" does not (he hopes), but a human isn't going to be involved (given that the process is going to be making hundreds of attempts per second).  So the cracker program presumably has to have some way to know that it has hit paydirt, or at least potential paydirt?  This would get especially dicey if the sender had encrypted the message twice or three times (Triple DES anyone?).

It just strikes me as incredibly unlikely that a given message encrypted using a secure method could EVER be cracked in finite time, especially if the attacker didn't know what he or she was looking for exactly.

If you have some known plaintext, then you can try all keys and find the one that decrypts to the known plaintext.  You might think this would never happen, but it's actually pretty common, due to protocol structure.

Alternatively, if you know the plaintext has some particular structure -- say, it is English text -- you can do trial decryptions and keep only the ones that produce something that looks like sensible English text.  For instance, you might check that the high bit of every character is off, or use letter or bigram frequencies.

For these reasons, it would be a mistake to think that this is a serious barrier to an attacker.  If the security of your system relies upon the assumption that the attacker won't be able to get known plaintext, or won't be able to recognize a valid decryption, then there's something wrong with the design of your system: it probably isn't as secure as you think it is.

For further details, here is a research paper on the subject:

David Wagner and Steven M. Bellovin.  A programmable plaintext recognizer.  1994.

Here's a quote from the paper: "Most types of text can be efficiently attacked: typically [...] we can expect to find the decryption key 90% of the time by using three ciphertext blocks.  Moreover, binary executables also fall to our ciphertext-only key search machine so long as the attacker knows for which architecture the binaries were compiled".


Can I detect a MITM attack? Based on this question here:
Are "man in the middle" attacks extremely rare?

Is it possible to detect man-in-the-middle attacks, and if so, how would one go about it?

In addition, what if the attack is taking place via connecting into the local network, such as phone lines?  Is there any way to detect it?

While browsing, you can check every time if the certificate that is presented to you by the website is issued by a legitimate CA or its a fake certificate issued by some CA that your browser trusts. Obviously it is not possible do it manually. So, there are tools that do it for you.

Cert Patrol and Perspective are browser plugins that do essentially that. They keep a note of which domainnames are issues by which CAs (eg. Google=>Thwate, etc.) and many other parameters related to the certificates and will alarm the user if either the CA changes OR if the public key in the cert changes.

These are obviously not detection of MITM, they are more like prevention schemes by detecting that something is odd about the certificate presented by the website.

Also while connecting to a SSH server, it asks for the server fingerprint. I'd be alarmed if my ssh client presents me a new fingerprint after I've previously connected to a server. The server host key gets saved to the known_hosts file after first connection, the only reason the client is asking me to validate the fingerprint again is because either the SSH server has restarted/updated OR I am being MITMed.

Absolute paranoia demands you to call the system admin on phone and confirm the fingerprint by making him speak the key.


What are the problems of using OTP encryption with TRNG? I've programmed a simple One-Time Pad "encryptor" that can merge two files into one by using bitwise XOR.

The pseudo-random key files are generated by using the CryptGenRandom() function from Microsoft's CryptoAPI library. Now I am wondering whether or not to code plugins for commercial True Random Number Generators.

My question is: what are the practical problems in deploying OTP with TRNG, other than requiring users to have the special hardware in the first place?

First, let's get some terminology straight. In order to call something a one-time-pad, the key must be truly random. So with that in mind:

You almost asked two separate questions:

I am using CryptGenRandom() to generate my key. Is this good enough or should I consider using a TRNG?
If I use a TRNG, what practical problems, if any, are there in deploying OTP with TRNG?

For Question 1, as I understand it, the only way anyone has ever successfully cracked (i.e. re-generated the proper seed) for CryptGenRandom() is by gaining access to the original machine where the key was created. And that was using a flaw in Windows 2000 which is 15 year old technology. So, based on that (combined with smart people at MS claiming it's cryptographically secure), I would argue that yes, CryptGenRandom() should be practically good enough to be used for key generation.

That being said, some high bit encryption should be good enough too, and if someone is thinking about using OTP instead of some other method of encryption, they are likely paranoid to the point that good enough isn't going to cut it. In other words, if you're going to implement something that you can truly call OTP, it must be absolutely impossible to crack your implementation without the key, which you cannot accomplish unless you use a TRNG.

As for Question 2, IMHO, there are no practical problems with using a TRNG. The reason is that only 1 trusted party involved in the communication needs to have the TRNG, not everyone. The harder problem is with key distribution, not key generation. The party with the TRNG (USB dongle or some other contraption) could generate a large set of random data, and then distribute the data to all involved parties. Each party when sending a communication would then simply need to specify the offset into the random data where their key begins. When the random data set is used up, a new data set can be generated.

However, the fact that someone involved in each communication has to initially obtain a hardware device in order to create the key may be considered a "problem", depending on how you look at it. This could have an effect on your "sales pitch", so to speak, since you won't appeal to impulse users who want to send a message with unbreakable encryption right now; all new users will have to wait some amount of time to obtain the TRNG device. You could consider using a service such as www.random.org, but if you do that, your ultra-paranoid users may not like the fact that the key is being downloaded over measly SSL!

TLDR; Regardless of whether you use CryptGenRandom() or a TRNG, the hard part is not actually in key generation, but in distributing the keys to each party so they can decrypt the message.