Re:Robinhood announces data security incident
by toomuchtodo on Monday November 08, 2021 @04:54PM
(#29154745)
“At this time, we understand that the unauthorized party obtained a list of email addresses for approximately five million people, and full names for a different group of approximately two million people. We also believe that for a more limited number of people—approximately 310 in total—additional personal information, including name, date of birth, and zip code, was exposed, with a subset of approximately 10 customers having more extensive account details revealed. We are in the process of making appropriate disclosures to affected people.”
Re:Robinhood announces data security incident
by potamic on Tuesday November 09, 2021 @11:07AM
(#29163564)
Looks like this is a very rudimentary miss in the processes. I wonder, wouldn't these guys be audited before they are allowed to operate? And if so, would the auditors be liable for anything for not catching such a trivial thing in the process?
Re:Robinhood announces data security incident
by argsv on Monday November 08, 2021 @09:19PM
(#29156938)
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.
Re:Robinhood announces data security incident
by runnerup on Monday November 08, 2021 @10:08PM
(#29157264)
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.
Re:Robinhood announces data security incident
by iso1210 on Tuesday November 09, 2021 @10:20AM
(#29162852)
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.
Re:Robinhood announces data security incident
by runnerup on Tuesday November 09, 2021 @10:50AM
(#29163313)
> 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.
Re:Robinhood announces data security incident
by runnerup on Tuesday November 09, 2021 @11:32AM
(#29163864)
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?
Re:Robinhood announces data security incident
by FreakLegion on Wednesday November 10, 2021 @02:56AM
(#29172190)
> - 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.
Re:Robinhood announces data security incident
by throwawaysea on Monday November 08, 2021 @09:50PM
(#29157148)
> 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.
Re:Robinhood announces data security incident
by emreb on Monday November 08, 2021 @04:24PM
(#29154472)
"The unauthorized party socially engineered a customer support employee by phone and obtained access to certain customer support systems." I guess the customer support system was open to the internet. In this day an age, how do you properly do perimeter fencing (as well as zero trust) for SaaS software?
Re:Robinhood announces data security incident
by wil421 on Monday November 08, 2021 @07:27PM
(#29156192)
The customer support systems we run do not have local logins and we use SSO and an identity provider that is only accessible on our company VPN. Other safeguards apply as well.
Since the company sells banking software and payment systems account numbers, cc numbers, and other identifiers are put into “sensitive” fields that are encrypted on our SaaS providers servers. We have a proxy server that decrypts the data in transit at our networks edge. Even the SaaS provider doesn’t have the keys to see these types of fields.
Re:Robinhood announces data security incident
by api on Monday November 08, 2021 @05:43PM
(#29155263)
Defense in depth. Put it on something like ZeroTier, but still secure it with hard key 2FA as if it's on the open Internet.
The key is always to make an attacker jump over more than one hurdle to get to anything. It's preferable if those hurdles are as isolated from one another as possible: different systems, different vendors, administrated by different people (multiple social engineering points), etc.
BTW I personally dislike this trend of trusting a single third party 2FA provider for access control to every system. It's incredibly convenient but it gives me the wim-wams. I'm waiting for a story like "Okta announces compromise, tens of thousands of sites may be at risk..." Never trust just one thing no matter what that one thing is.
Re:Robinhood announces data security incident
by jimmydorry on Monday November 08, 2021 @05:15PM
(#29154977)
2FA doesn't seem like a golden bullet here, where if I understand the attack vector correctly, the malicious party convinced support to grant them access (presumably since they claimed to be working from home).
If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same.
Re:Robinhood announces data security incident
by omegalulw on Tuesday November 09, 2021 @01:19PM
(#29165257)
> If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same.
Nope. You won't ship keys to some random address - you will do it to the address on file. Presumably, changing address on file would be guarded by rigorous processes.
Re:Robinhood announces data security incident
by doubled112 on Monday November 08, 2021 @06:18PM
(#29155616)
I'm mostly playing devil's advocate, but there could definitely be a process around that 2FA token that isn't there for a password reset.
Verifying the employee's mailing address vs just replying to them over the phone or email sounds like a hurdle. Might not be the same person shipping out the token, so now you have to prove it to two people. Blockers like that.
Re:Robinhood announces data security incident
by jimmydorry on Monday November 08, 2021 @05:13PM
(#29154950)
Good question. In the COVID-19 age and WFH era, companies should consider adding support policies that require visual identification (video call with photo ID on company file to compare against) as a bare minimum for giving someone remote access via support ticket.
Re:Robinhood announces data security incident
by ljm on Monday November 08, 2021 @05:43PM
(#29155260)
Companies should keep their critical infra behind their own VPN as much as they possibly can and for the things that can't be VPN'd, use an SSO with strong MFA support.
Especially for remote work - any critical or internal infra should be behind a company-operated VPN, with the VPN-access gated by MFA.
It's obviously not foolproof because the more SaaS you add, the more vulnerable you are, especially because security in HN-land is something you only worry about after-the-fact because it's not MVP or quick to market. But asking for more personal info is perhaps the worst possible conclusion you could take from this.
At some point you have to stop asking your users to take responsibility for your own shoddy security.
Re:Robinhood announces data security incident
by sofixa on Tuesday November 09, 2021 @06:50AM
(#29160425)
Zero trust has been gaining more and more popularity over the traditional hiding behind a VPN and trusting everything behind it. A VPN, if there's one ( it's still useful and avoids unauthenticated exploits on software), should be the first line of defence.
Re:Robinhood announces data security incident
by wil421 on Monday November 08, 2021 @07:34PM
(#29156234)
Bingo. The company I work for even gives certain locales, that are prone to IP theft, VDI only access to company systems. They are given a laptop with nothing on it except tools to access the VPN and VDI.
Re:Robinhood announces data security incident
by niros_valtos on Tuesday November 09, 2021 @07:12AM
(#29160603)
When security impacts productivity it becomes a difficult battle. Zero trust tries to solve the VPN requirement, but as we all know, the devil is in the implementation details…
Re:Robinhood announces data security incident
by bink on Monday November 08, 2021 @05:22PM
(#29155057)
I'm not sure this is saying they stole credentials and used them from outside the customer support rep's computer. It could be that they tricked the support rep into installing malware and followed them into the systems.
Re:Robinhood announces data security incident
by ryanar on Tuesday November 09, 2021 @09:09AM
(#29161905)
One solution is to integrate with one of the up-and-coming zero trust products. This is a new space that was started by the company I work for strongDM, and there are a number of startups competing in this space. I would highly recommend looking into it if you want to be more secure than a VPN's model of once you are inside the wall you are trusted.
Re:Robinhood announces data security incident
by klee0102 on Monday November 08, 2021 @06:52PM
(#29155923)
How exactly can a customer support be tricked and then hown did a support can give out access to the customers data? The fancy language used add more questions than answers.
Re:Robinhood announces data security incident
by toomuchtodo on Tuesday November 09, 2021 @10:30AM
(#29163001)
Lax controls and incentives. There will be no repercussions to Robinhood from this event, so there is no incentive to build robust controls in their systems.
Re:Robinhood announces data security incident
by twalla on Tuesday November 09, 2021 @10:41AM
(#29163180)
For anyone still using Robinhood: it's incredibly easy to file an ACATS with another, more reputable broker - depending on the broker and how much you're transferring, the 70 dollar fee is often waived. I've been very happy with Fidelity since the whole GME debacle.
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.
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.
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.
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.
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 keyJust 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?
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.
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.
Since the company sells banking software and payment systems account numbers, cc numbers, and other identifiers are put into “sensitive” fields that are encrypted on our SaaS providers servers. We have a proxy server that decrypts the data in transit at our networks edge. Even the SaaS provider doesn’t have the keys to see these types of fields.
The key is always to make an attacker jump over more than one hurdle to get to anything. It's preferable if those hurdles are as isolated from one another as possible: different systems, different vendors, administrated by different people (multiple social engineering points), etc.
BTW I personally dislike this trend of trusting a single third party 2FA provider for access control to every system. It's incredibly convenient but it gives me the wim-wams. I'm waiting for a story like "Okta announces compromise, tens of thousands of sites may be at risk..." Never trust just one thing no matter what that one thing is.
If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same.
Nope. You won't ship keys to some random address - you will do it to the address on file. Presumably, changing address on file would be guarded by rigorous processes.
Verifying the employee's mailing address vs just replying to them over the phone or email sounds like a hurdle. Might not be the same person shipping out the token, so now you have to prove it to two people. Blockers like that.
Especially for remote work - any critical or internal infra should be behind a company-operated VPN, with the VPN-access gated by MFA.
It's obviously not foolproof because the more SaaS you add, the more vulnerable you are, especially because security in HN-land is something you only worry about after-the-fact because it's not MVP or quick to market. But asking for more personal info is perhaps the worst possible conclusion you could take from this.
At some point you have to stop asking your users to take responsibility for your own shoddy security.