5 ms·
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 i
by argsv 5y ago
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.
- throwawaysea 5y ago> 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.
- runnerup 5y agoWhat'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 5y agoHashing 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 5y 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.
- iso1210 5y agoHow? 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 5y agoI'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?
- jedimastert 5y agoSmall 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.