zlacker

It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.

>>ggm+(OP)
TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe).

Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.

>>ggm+(OP)
Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa).

The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.

This is why it's switched on good platforms to "type in the number you see", which mitigated this.

>>hirsin+0g
That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers.

The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.