Live data from Hacker News

When MFA isn't MFA, or how we got phished

retool.com

51–60 of 287 posts

Re: When MFA isn't MFA, or how we got phished

#51
post #11

Earlier quoted context omitted.

What’s this got to do with zero trust?

it is a cynical comment that is meant to hilite the relationship between humans where oppressive and untrusting employment leads to increase in antipathy, ill-will, feelings of being abused and all of that leading to insider theft and serious pre-meditated betrayal ?

Zero Trust is such a bad branding for how the architecture works. It's just "always prove" architecture.

Re: When MFA isn't MFA, or how we got phished

#53
post #22

Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…

>FIDO2 can also detect the domain making the request, and will not provide the correct code even it the page looks correct to a human. I could not agree more with this sentiment! We need more of this kind of automated checking going on for users. I'm tired of seeing "just check for typo's in the URL" or "make sure it's the real site!" advice given to the average user. People are not able to do this even when they kno…

The problem with Fido (and other such solutions, including smartphone-based passkeys) is that they make things extremely hard if you're poor / homeless / in an unsafe / violent family situation and therefore change devices often. It's mostly a non-issue for Silicon Valley tech employees working solely on their corporate laptops, and U2F is perfect for that use-case, but these concerns make MFA a non-starter for the wider population. We could neatly sidestep all of these issues with cloud-based fingerprint readers, but the privacy advocates won't ever let that happen.

Re: When MFA isn't MFA, or how we got phished

#54

Fantastic write-up. Major props for disclosing the details of the attack in a very accessible way. It is great that this kind of security incident post-mortem is being shared. This will help the community to level-up in many ways, specially given that its content is super accessible and not heavily leaning on tech jargon.

I disagree. I appreciate the level of detail, but I don't appreciate Retool trying to shift the blame to Google, and only putting a blurb in the end about using FIDO2. They should have been using hardware keys years ago.

It was also a bit weird how they kept emphasizing how their on-prem installations were not affected, as if that lessens the severity somehow. It's like duh, that's the whole point of on-prem deployments.

Re: When MFA isn't MFA, or how we got phished

#55
post #24

Earlier quoted context omitted.

> I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone Why don't you use the printed recovery tokens?

Who has a printer these days?

Local libraries, print shops... but yeah that may be an attack vector.

Re: When MFA isn't MFA, or how we got phished

#58
post #22

Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…

> Very sophisticated attack, I would bet most people would fall for this. No. If you think people at your company would fall for this, then IMO you have bad security training. The simple mantra of "Hang up, lookup, call back" ( https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo... ) would have prevented this. Literally like 99% of social engineering attacks would be prevented this way. Seriously, make a lit…

This fails to satisfy one of the core lessons here: trust nothing, not even your own training and culture.

Re: When MFA isn't MFA, or how we got phished

#59
post #22

Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…

[dead]

Re: When MFA isn't MFA, or how we got phished

#60
Question for security folks out there:

So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system.

Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive systems like internal admin tools? I'm thinking like the "turn the two keys simultaneously to launch the missile" systems. I'm thinking it would work like the following:

1. If a system detects a user is logging into a particularly sensitive area (e.g. a secrets store), and the user is from a new device, the user first needs to log in using their creds (including any appropriate MFA).

2. In addition, another user like an admin would need to log in simultaneously and approve this access from a new device. Otherwise, the access would be denied.

I've never seen a system like this in production, and I'm curious why it isn't more prevalent when I think it should be the default for accessing highly sensitive apps in a corporate environment.

Post reply on HN