Robinhood announces data security incident | Hacker News Reader

Robinhood announces data security incident

blog.robinhood.com

137 pointsmarc__132 comments

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

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?

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.

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

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.

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

2FA with hard tokens seems common. There's also authenticating gateways/proxies and SASE products

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.

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.

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

Much like giving keys to the kingdom (access to internal systems) was guarded by a rigorous process. xD

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.

and then, the deepfakes

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.

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.

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…

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.

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.

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.

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.

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.

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.

How exactly can anyone, no matter what the credentials, access 5 million records?

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.

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.

robinhood continues to show their utter incompetence

Reply on news.ycombinator.com