Hashing SSNs and other limited-domain information

I'm currently working on an application where we receive private health information. One of the biggest concerns is with the SSN. Currently, we don't us开发者_如何学Pythone the SSN for anything, but in the future we'd like to be able to use it to uniquely identify a patient across multiple facilities. The only way I can see to do that reliably is through the SSN. However, we (in addition to our customers) REALLY don't want to store the SSN.

So naturally, I thought of just SHA hashing it since we're just using it for identification. The problem with that is that if an attacker knows the problem domain (an SSN), then they can focus on that domain. So it's much easier to calculate the billion SSNs rather than a virtually unlimited number of passwords. I know I should use a site salt and a per-patient salt, but is there anything else I can do to prevent an attacker from revealing the SSN? Instead of SHA, I was planning on using BCrypt, since Ruby has a good library and it handles scalable complexity and salting automagically.

It's not going to be used as a password. Essentially, we get messages from many facilities, and each describes a patient. The only thing close to a globally unique identifier for a patient is the SSN number. We are going to use the hash to identify the same patient at multiple facilities.

The algorithm for generating Social Security Numbers was created before the concept of a modern hacker and as a consequence they are extremely predictable. Using a SSN for authentication is a very bad idea, it really doesn't matter what cryptographic primitive you use or how large your salt value is. At the end of the day the "secret" that you are trying to protect doesn't have much entropy.

If you never need to know the plain text then you should use SHA-256. SHA-256 is a very good function to use for passwords.

If you seriously want to hash a social security number in a secure way, do this:

1. Find out how much entropy is in an SSN (hint: there is very little. Far less than a randomly chosen 9 digit number).
2. Use any hashing algorithm.
3. Keep fewer (half?) bits than there is entropy in an SSN.

Result:

• Pro: Secure hash of an SSN because of a large number of hash collisions.
• Pro: Your hashes are short and easy to store.
• Con: Hash collisions.
• Con: You can't use it for a unique identifier because of Con#1.
• Pro: That's good because you really really need to not be using SSNs as identifiers unless you are the Social Security Administration.

First, much applause and praise for storing a hash of the SSN.

It appears as if you're reserving the SSNs as a sort of 'backup username.' In this case, you need another form of authentication besides the username - a password, a driver's license number, a passport number, proof of residence, etcetera.

Additionally, if you're concerned that an attacker is going to predict the top 10,000 SSNs for a patient born in 1984 in Arizona, and attempt each of them, then you can put in an exponentially increasing rate limiter in your application.* For additional defense, build in a notification system that alerts a sys-admin when it appears that there is an unusually high number of failed login attempts.**

*Example exponentially increasing rate limiter: After each failed request, delay the next request by (1.1^N) seconds, where N is the number of failed requests from that IP. Track IP and failed login attempts in a DB table; shouldn't add too much load, depending on the audience of your application (do you work for Google?).

**In the case where an attacker has access to multiple IPs, the notification will alert a sys-admin who can use his or her judgment to see if you have an influx of stupid users or it's a malicious attempt.