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.
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?
> - 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.
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.