[HN Gopher] Robinhood announces data security incident
___________________________________________________________________
Robinhood announces data security incident
Author : marc__1
Score : 47 points
Date : 2021-11-08 21:10 UTC (1 hours ago)
(HTM) web link (blog.robinhood.com)
(TXT) w3m dump (blog.robinhood.com)
| dzader wrote:
| robinhood continues to show their utter incompetence
| twirlock wrote:
| I have no faith whatsoever that they would be forthcoming about
| the extent of any breach.
| emreb wrote:
| "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?
| nijave wrote:
| 2FA with hard tokens seems common. There's also authenticating
| gateways/proxies and SASE products
| jimmydorry wrote:
| 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.
| jimmydorry wrote:
| 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.
| ljm wrote:
| 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.
| mam4 wrote:
| and then, the deepfakes
| api wrote:
| 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.
| nyxaiur wrote:
| You can't move fast and break things with fences around.
| bink wrote:
| 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.
| toomuchtodo wrote:
| "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."
___________________________________________________________________
(page generated 2021-11-08 23:01 UTC)