Hashing SSNs and other limited-domain information

Question

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 use the SSN for any

Answer 1

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.

Answer 2

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.

Answer 3

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.