Hacker News Reader

Comment by argsv | Hacker News Reader

I don't trust the first release or the first disclosure. I expect Robinhood in the next few days to disclose that the exposure was wider and more serious than initially thought.

It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it.

Their track record isn't that of a company to be trusted.

View on HN

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.

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.

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

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

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.

Small nit, but at this point I barely consider SSNs to be non-public knowledge, and it was never made to be. Just a record identifier.

> It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it.

That's really scary and feels like it is more than basic in 2021. I really wish we had legislation to protect users against this type of stuff, or at least to grant them some avenue for compensation.

Reply on news.ycombinator.com