Live data from Hacker News

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

retool.com

11–20 of 287 posts

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

#12
post #5

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.

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.

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

#13

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”

man you should see what people are getting up to with evilginx2 these days. They are registering homoglyph URLs just for your and running MITMs that passthru the real site 1:1, and forwarding to the real thing once they skim your login token so you never even notice. The really crappy phishes and jankfest fake sites are pretty much obsolete.

Then they hang out in your inbox for months, learn your real business processes, and send a real invoice to your real customer using your real forms except an account number is wrong.

Then the forensics guy will have to determine every site that can be accessed from your email and if any PII can be seen. What used to be a simple 'hehe i sent spam' is now a 6 month consulting engagement and telling the state's attorney general how many customers were breached.

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

#14
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

For me the question is "who the fsck uses Google Authenticator to store all their tokens, both company and personal?"

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

#16
post #8
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.

Well that's even worse isn't it?

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

#17
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 over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward.

They needed to have a couple of minutes to set things up from their end, and then ask for the second OTP code. A phone call works well for that.

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

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

A better way to fix this is to have multiple ways to log in. Printed backup codes in your safe with your personal papers and/or a Yubikey on your keychain. This works for Google and Github, at least.

Passkey syncing is more convenient, though, and probably an improvement on what most people do.

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

#19
post #11

Earlier quoted context omitted.

how's that Zero Trust architecture working out for everyone ?

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 ?

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

#20
post #9
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

Answering myself, this helps a bit: https://www.zdnet.com/article/google-authenticator-will-now-... I guess we need a better way to handle "Old phone went swimming, had to buy another, now what?"

Which is funny because the 2nd factor is "something I have", which means if you don't "have it" then you can ever complete the 2nd factor. This ultimately means the 2nd factor, when you're phone goes swimming, is ultimately your printed codes.
Post reply on HN