TOTP with a changing code is simple to understand and use and very resistant to both SIM Swapping and all these push based notification attacks. Push based notification attacks are relatively easy to social engineer as well - call, say you need to confirm identity and push.

Passkeys are a nightmare. For whatever reason they play SO SO badly. Microsoft / et al all seem to compete to screw this stuff up. Seriously, if you are logged into a remote desktop, the push goes through chrome to some microsoft thing which has a different pin / password / whatever. What's even crazier - I have a yubikey and somehow the passkey doesn't need the actual hardware key to be plugged in - so this passkey is being stored somewhere else.

Keep it simple. I liked the U2F yubikey flow where you had to touch the yubikey to authenticate and I like TOTP well enough as well.

This, I find passkeys very difficult to understand.

It seems I can use my phone as my "passkey". Okay nice, that should mean I can use the same one on multiple devices, just like with a hardware Yubikey, right? Well apparently no. Use a phone as a passkey on one device for a web account, try to log into the same account on another device, using the phone passkey, and it doesn't work, claims there is no passkey. I can't see what passkeys are actually present on the phone, so I don't know what's wrong.

There's so many different ways to have and use passkeys, and no way to tell what the status is. I have no idea how the less-technical users are supposed to be able to figure this stuff out.

Totally - it's super confusing! Apple actually seems to let me plug my passkey into my device (including my phone) and then it works. But I'm not native apple - all my work stuff is Windows / Linux etc. And passkey is garbage there. I think even bitwarden is trying to hijack the passkey now. How is this a second factor? If my vault password is taken, and the passkeys are in the vault - then aren't you screwed.

The whole point of a little yubikey is that if someone gets my password, they also have to get the yubikey. The chances of that, while not zero, are MUCH smaller. And then I can do a little recovery envelope with a yubikey in it as a backup.

When you created the passkey, there was an option to store it on an external security key. It was probably some smaller text or a button towards the bottom of the confirmation dialog.

Since most users would prefer to store it in iCloud (or competitor) and have it synced to all their devices, that’s the default. But you can keep using external security keys in this new passkey-based world. You just have to opt-in to it.

And yes, I agree that external security keys offer better security, at the cost of a little convenience.

I've tried to use an a key on a device, but they DON'T seem to work everywhere. If I use an apple phone for my key, how does that work with Chrome on Windows or just for Windows logins?

If I'm using whatever windows is pushing (maybe INSIDE windows - so if they get my pin/password I'm hosed?) how does that work on my iphone or for Apple TV login?

The whole thing is a freaking mess. U2F or whatever came before was so easy by comparison. Seemed to work very well cross platform. If you had a NFC version you could bring it close to your phone and touch a button and voila - authenticated. Or plug into a computer and touch a button. And it seemed to work with Chrome / Windows etc etc.

I hit the "not me" button _once_ in the MS Authenticator app. Never touching that button again.

What happened was that I was immediately logged out from most systems and had to call IT to unlock my account. Apparently Outlook had initialised a login request after the 14 days validity of the previous authentication in the background with no indication on my screen that it had done so.

I’ve long been curious what happens, especially since it would be an easy mistake to make even if you didn’t intend to do so. Thanks for establishing that I never wish to experiment with it.

It’s very likely the case their employer had configured some kind of feature set and logic to respond to the denial. Out of the box, Microsoft Entra doesn’t do that kind of thing.

This is why I only use TOTP, my company IT was even baffled when I chose TOTP instead of the MS Authenticator app.

I don't use Authy or any of them that backup to the cloud either, since that defeats the whole point. Every time I add a new TOTP, I add it to an old OnePlus phone as a backup, and that is at home 24/7 in case I lose my main phone.

After having someone try and hijack my NPM account, and actively pursuing me for a bit, I realized all other forms of 2fa are a joke. They will impersonate you to your carrier, they will try to get you to send them the code to hijack your sim... It's basically a matter of time for any large scale organization has one employee who drops the ball.

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).

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.

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).

Why can’t orgs wise up and use security keys? Push based and SMS MFA are nothing but threat vectors.

Push/prompt gating security (or most things) is bad - a lesson we keep learning[1] for myriad UI issues.

One thing I would say though is while it's technically bad that this person hit "approve" after being bombarded with notifications, limiting repeated authentication and exponential delay on sign in attempt is one of the most basic security protections that any authentication mechanism or service should implement and failing to do this is a pretty basic and fundamental failure on the part of that service.

[1] It was frustrating to me when I worked on browsers where people kept trying to add extremely privileged functionality to the browser and then claiming there were no security problems because you could prompt the user. But it happens everywhere, I think Raymond Chen had a post many years ago regarding how the windows installer used to prompt people to replace files but would keep asking until people thought they were answering wrong, which then led to non-booting machines.

Looks like even push notifications can be too pushy! The LA County Health Department got breached because someone got so many login alerts they just gave up and hit "approve." Cybersecurity lesson: sometimes, less is more.

Nope, the proper lesson is to provide a secret (such as a 2 digit code) with the 2FA request that the authenticator must also present instead of just hitting "approve".