Hacker News new | ask | show | jobs
by teeray 725 days ago
Push-based MFA is a mistake for this exact reason. I don’t know why it seems every service opposes implementing pull-based TOTP, but it is strongly resistant to this abuse (since there are no notifications involved).
3 comments

Throttling and/or an exponential back off would fix this though.

If I hit no, it better be 5 minutes before the next one is allowed through. And then 15min, then 2hr, etc.

Fatigue should have been considered in both the server and the client.

Makes sense. Pretty much the only reason a user would hit "no" is that they aren't trying to log in, and because the prompt is only sent after the correct password has been provided, if there are more than a couple in a row the account should be disabled entirely or at least set to demand a password change after the next successful login.
The problem is these are settings in an idp, and if you do not have competent or resourced practitioners operating these systems (iam/security engineer), you're going to get punched in the face because you didn't tune the right flag/setting and humans are the weakest link in the system. Number matching and auth throttling would've defeated this attack trivially.

Edit: Strongly encourage upgrading to passkeys as soon as an org can, Entra recently launched GA support a few months ago.

https://learn.microsoft.com/en-us/entra/identity/authenticat...

https://learn.microsoft.com/en-us/entra/identity/authenticat...

(i do security things at a fintech and own the idps, thoughts and opinions my own)

What are the right flags for using TOTP? I thought it's so standard now, it's basically fool-proof, as long as you set the number of digits and the timeout correctly, and the default 6 digits and 60 seconds are just fine.

Where's the catch?

If you do push auth, require the user enter a number provided. Throttle auth attempts to something reasonable based on your user population. Lockout auth after X number of bad attempts and require escalation. Provide a way to report unapproved auth attempts received (which should get piped to your incident response and identity compromise playbook(s)). This should stop any brute force attack in its tracks.

For TOTP, I prefer 30 second TTLs for the OTP. A tight window makes it very difficult to phish if you must support a user using TOTP. If someone has challenges with this due to the short window, upgrade them to device bound passkeys.

What is "pull based TOTP"?

Is it a prompt when you login to "text 123456 to 555-444-3333" and wouldn't that be pretty trivial to forge to appear to be coming from the account owner's phone (if you knew its phone number)?

I mean specifically OATH TOTP—nothing involving SMS. In this threat model, an attacker would not have a phone number or email address for the target—only a username and their stolen password (from a breach).