Earlier quoted context omitted.
inside job?
how's that Zero Trust architecture working out for everyone ?
When MFA isn't MFA, or how we got phished
11–20 of 287 posts
Re: When MFA isn't MFA, or how we got phished
#12Naming/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.
"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
#13Naming/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”
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
#14I 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
Re: When MFA isn't MFA, or how we got phished
#15Perhaps we need a distinction from phishable MFA and unphishable U2F/WebAuthn style
Re: When MFA isn't MFA, or how we got phished
#16Re: When MFA isn't MFA, or how we got phished
#17Why 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 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
#18I 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.
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
#19Earlier quoted context omitted.
how's that Zero Trust architecture working out for everyone ?
What’s this got to do with zero trust?
Re: When MFA isn't MFA, or how we got phished
#20I 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?"