| HN Mirror

Y	Hacker News new \| ask \| show \| jobs


	by runnerup 1686 days ago
	What's the point of encrypting SSN's? There's only a billion naive permutations..much less if you eliminate "impossible" ones like the SSN prefixes reserved for children of railroad workers. Even if you add a unique salt for each account, brute forcing the hashes wouldn't take very long, assuming the salt was leaked (and most of the time the salt for each account would be in these dumps). Brute forcing this order of difficulty was considered "done" around 2014 for SHA-1. I suppose you could add enormous number of recursive hashes or an immensely expensive parameter selection for bcrypt. But I feel most realworld implementations of hashed SSN would be only little better than plaintext.

1 comments

iso1210 1686 days ago

Hashing SSN (or credit card info) is pretty pointless. Encrypting it however is important.

Obviously if you lose the key you're stuck, but then people don't need to know the key, it should be behind an API.

The service which provides the decoding for a given encrypted record to an authenticated user should provide it, and audit it, and have rate limits. Even if the database leaks, it's encrypted, if the credentials to someone who needs access to that SSN are stolen, you could only use it a few times a day to avoid flagging up as unusual activity.

link

runnerup 1686 days ago

> Even if the database leaks, it's encrypted

My point is that with only one billion SSN combinations, it's easy to brute force the two way encryption in the same way you would brute force a one way hash.

link

iso1210 1686 days ago

How?

Here's a 4 digit number that's encrypted with a key.

How am I going to decode that without the key?

And here is the same number encrypted with the same key

link

runnerup 1686 days ago

I'm disappointed that I needed the point made to me in this way...and glad I'm not using an account associated with my real name. Obviously with a sufficiently large key-space my silly idea wouldn't be possible merely because the content-space is small.

Just to continue the conversation and maybe learn more, I think it's a safe assumption that generally:

- either a unique key would be stored in the database for each user similar to a salt (vulnerable to DB dump)

- or the key would be determinate from other info associated with each user (which would be reversible from hypothetical additional leaked source code)

- or there is a hardcoded key used for every single SSN (which would be vulnerable to `echo $ENV` or similar if attacker had shell access to the appropriate machine)

While not all database dumps will be done by someone with long-term root level access, is there a method which would secure SSN's against someone who has the access levels necessary to pull off the three above attacks?

link

FreakLegion 1685 days ago

> - either a unique key would be stored in the database for each user similar to a salt (vulnerable to DB dump)

Sort of. A financial institution will invariably encrypt with AES-256, so the unique value would be a 256-bit initialization vector, or IV. Usually that's fancy talk for "one-time pad XOR'd against the first block of plaintext before encrypting", but it depends on the cipher mode.

> is there a method which would secure SSN's against someone who has the access levels necessary to pull off the three above attacks?

Yes, for example AES with an IV (among many others). The IV isn't secret and revealing it to an attacker doesn't compromise the encryption at all.

link