[argsv]

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.

[runnerup]

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.

[iso1210]

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.

[runnerup]

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

[iso1210]

How?

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

How am I going to decode that without the key?

    -----BEGIN PGP MESSAGE-----

    hQIMAx9jORqt77qhAQ/+PqevCv0hxzqszwAbWeYAlvvnKmAL6kfzjuXcW5r/nb3i
    0ilteYnJ4VR3xDqoHgOUukPnXYlxOwskzGKpHrojXUndIQBu6M9uGXobU/j5yQRU
    fxDWNdNe0s5tCySsplbCRvNzVy9688uwXXASLEFynofG0/9ur826nXLB+yP7JBHn
    1/hmOWq8LoH6VZ0HnFyvmM82Fpyf0WnqzS41Ck+jZzD3dZx3NLpaUU0N7+IpTMaK
    CqwW/sDKo0JqduoaDVlzf02LX6FHETQJfzZahNC+7/4fsz/mpcc4n8cTAdyCHE2M
    BG1LNp1cQhtU2/J2p0M2hlupsorRcqixV2fTQ+SX6/dT3AGier917mwgLlzQtxQB
    TdiupSizVIqCAQmy3RiiyitFXRaaHF5g/sNHw86i/FntNT8AnoHFJNddaCdwZl/y
    S3CNhJDLxKqGNd1qemCLR74fW0C3zNSfqvSgHbX7Q0sIH9T5atKaphi0HreAD99f
    CKI/cSiHSm6IBUmMYWX7XDs14OBkVEV5BrtXVcK/6ek4FOEBMR8A5LugCgAzA2aH
    a65pUaQkcvDMKKR47UCDk3aNJPDDtZe6xSaRiUns6PKO1roY6kTiy3z3cqhbzM8/
    +DevVIVhMwBYk3zAjQwpQEMlRaS9zfMnFBVv9I4c2PBTlc9xz+VCTIcx8E5hdgvS
    PwFWgymFu4lg5BVYQ+xabJJQqW83j/1QafwrZybEWCkkc72uJE/w6KnkZY4YToxW
    Ru2GcW3Vjhxt+YU/NepOAw==
    =xrm9
    -----END PGP MESSAGE-----

And here is the same number encrypted with the same key

    -----BEGIN PGP MESSAGE-----

    hQIMAx9jORqt77qhAQ/9GQaf7kbC705yYvEd8cCBLo9Fe7oIczYlr8AT3VJiWzBY
    Cv2COLIgFZJVg88pfEiymJgftGZFmwT2Dt1Z67WdAMqQ65ZqaTqdDJ39fpfXeOmm
    PtWM2dGPxTXwWS9mYquOGTQpDNCb6skBorb6+GSHmCNW00fMkFY1HOjB+LuQMVVm
    tlx26fEHb5OZTusIIj5+dA07xIgf0IQfPED4nXk1wNpjBtaGToukURWtFmjsk64k
    j6wcTlutGc9mzGFo9Jj81KC85nuEj+CgHzX398/FOQ0uoj9/yj9hsRB1oruSBuAU
    z1a0yuUpZ9B7EhSg7uVhfp7tTZAyRRwUFHrrNX4LTBk/XSDYrrnxP83HKj1LiIMX
    /wlaWk01y9heU9LdkR+VjGVmAy1vhYlUCdIkF8CfOJgPGtP7pnJj2zdpEH2v8rFO
    fz8W0sDtT55eM3xUdbVUeUjf6F+46TOxKKZsheKDGRwlprMg47vRkcjguVx9WSvv
    K/GNIRrohAwF/ftEzFVGpv+96gsmPvjx6F5Jz4520gnMFeCVMzg5EugGjzb8ulSc
    AFC8vD2L1F6CPII2CZkxjw74sdRgK6kyKvD8jJAa8Vd+qwdABBkBu+Ol2ptJXzX2
    O53fbiqlY45ujl3pI13YNlRrumZ1pWzkunXeDovwXkMjV6LVFZmHhDPmibmcTczS
    PwEzZa2wFauMQkLOc6m5fgmTP2RTYOWeWGMTXlnstw+a/fZ+uo9GZtKyon//7vOh
    f1dez3nXdKJwMx3Z+2ZUiQ==
    =W9zc
    -----END PGP MESSAGE-----

[runnerup]

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?

[FreakLegion]

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

[jedimastert]

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.

[throwawaysea]

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