Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

retool.com

Post reply on HN
Print view View original

21–30 of 287 posts

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

#21

Post by AshamedCaptain »

unethical_ban wrote: post #12
mr_mitm wrote: post #5

Earlier quoted context omitted.

It's well known that OTP is not immune to phishing. Force your users on webauthn or some other public key based second factor if you're aiming at decreasing the incident rate.

Well, push based 2fa with "select this number on your 2fa device" helps prevent some vectors. Simple totp doesn't do that. "Never give your totp or one time code over the phone" is good advice. "Never give info to someone who called you, call them back on the official number" is another. This is user error at this point.

I disagree. Specially again that companies are centralizing on a couple 2FA companies (like Okta from TFA), this is just ripe for phishing. Okta itself is terrible at this; they don't consistently use the okta.com domain, so users are at a loss and have basically no protection against impersonators.

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

#22

Post by rolobio »

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 the request, and will not provide the correct code even it the page looks correct to a human.

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

#23

Post by wepple »

rsstack wrote: post #17
wepple wrote: post #15

Why did they need to call? They could’ve phished the password and MFA by simply MITMing? Perhaps we need a distinction from phishable MFA and unphishable U2F/WebAuthn style

> The caller claimed to be one of the members of the IT team, and deepfaked our employee’s actual voice. The voice was familiar with the floor plan of the office, coworkers, and internal processes of the company. Throughout the conversation, the employee grew more and more suspicious, but unfortunately did provide the attacker one additional multi-factor authentication (MFA) code. > The additional OTP token shared ov…

Ahh, thanks and apologies for not re-reading before asking.

That is indeed interesting; keep the con going a bit longer to get a proper foothold.

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

#24

Post by itake »

unethical_ban wrote: post #10
kerblang wrote: post #6

I don't understand: Why on earth does google want to sync MFA tokens? They're one-time use, aren't they? Or... feh, I can't even fathom

Syncing of "MFA codes" is really syncing of the secret component of TOTP (time based one time password). And it's a good thing, and damn any 2fa solution that blocks it. I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone. So I use authy personally, while a friend backs his up locally.

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

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

#26

Post by softfalcon »

rolobio wrote: 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 know how to protect themselves. Humans tire easily and are often fallible. We need more tooling like FIDO2 to automate away this problem for us. I hope the adoption of it will go smoothly in years to come.

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

#27

Post by monocasa »

itake wrote: post #24
unethical_ban wrote: post #10

Earlier quoted context omitted.

Syncing of "MFA codes" is really syncing of the secret component of TOTP (time based one time password). And it's a good thing, and damn any 2fa solution that blocks it. I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone. So I use authy personally, while a friend backs his up locally.

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

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

#28

Post by jpc0 »

mr_mitm wrote: post #5
pyrolistical wrote: post #4

Naming/training issue imo. We need a better name than MFA. Something like “personal password like token that should only be entered into secure computer on specific website/app/field and never needed to be shared”

It's well known that OTP is not immune to phishing. Force your users on webauthn or some other public key based second factor if you're aiming at decreasing the incident rate.

I blame SAML and any other federated login being an "enterprise only" feature on most platforms.

So users get used to sharing passwords between multiple accounts and no centralised authority for login. This causes the "hey what's your password? I need to quickly fix this thing" culture in smaller companies which should never be a thing in the first place.

If users knew the IT department would never need their passwords and 2FA codes they would never give them out, the reason they give them out is because at some point in the past that was a learned behaviour.

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

#29

Post by AYBABTME »

To deepfake the voice of an actual employee, they would need enough recorded content of that employee's voice... and I would think someone doing admin things on their platform isn't also in DevRel with a lot of their voice uploaded online for anyone to use. So it smells like someone with close physical proximity to the company would be involved.

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

#30

Post by kerblang »

jeremyjh wrote: post #8
kerblang wrote: post #6

I don't understand: Why on earth does google want to sync MFA tokens? They're one-time use, aren't they? Or... feh, I can't even fathom

They mean they are syncing the private key used to generate the tokens on demand.

Do all these 2FA apps - like say Microsoft Authenticator - have these hidden/not-so-hidden private keys? From other posts it sounds like you can view the token and write it down... MA doesn't have that, I don't think.
Post reply on HN