> it shifts the attack from a passive opportunistic one to a targeted one

This isn't true. You can bulk phish SMS, TOTP and the push confirmation stuff. Software to do this isn't theoretical you can just download it ready to use, because in each case you only need to fool a human into believing this is really their bank/ web mail/ government/ etc.

If you want to get rid of the opportunistic stuff you need technology like WebAuthn that makes it simply not work.

> The smart thing would be for MSFT/o365 to give you the option to switch to a TOTP token and other authenticators with a better experience so people can switch organically.

It already does, both through an app notification using the Microsoft Authenticator TOTP app, as well as through the app-agnostic TOTP method. (Just checked my own settings.) It's just not the easiest thing to find the settings page where you do it, because Microsoft helpfully hides it behind "advanced security options" instead of just putting it next to the "change password" UI like the other major sites do.

> Most security people still don't distinguish between authenticators and identities, as federation concepts like identity providers are still in the rarefied space of enterprise.

Who are you counting as "security people" in this case? I feel like the distinction for that kind of thing has been around for a long, long time, as evidenced by SSH public key configs and Active Directory certificate based login configuration both allowing multiple keys/certs per user, or Github allowing multiple keys as access tokens, etc. If we're talking about OTP keyrings issued by banks to consumers, again I don't think those things have been equated to identity as much as being treated like a second key for a second lock on the same door.

Beyond marketing, I've never understood SMS as the default 2FA over just using a second email as the 2nd factor.

Everyone has a 2nd email, personal + work or school.

You could argue that both emails are probably accessible from an email app on the phone, but if the phone is stolen, then that's no worse than SMS or ToTP apps also on the phone.

You could argue password reuse, but if the address used for 2FA is never exposed to the end user after being set+verified, then the attacker would have no way of knowing the victim's 2nd email address.

Unless the attack is targeted... But if the attack is targeted, then we're back to SMS being vulnerable.

So, what it comes down to is 2nd email as 2FA is more secure and more efficient than SMS out of the gate... (and much cheaper)...

And, if I use a very obscure and otherwise not used email (with its own security + strong password), even a targeted attack has no better chance than a ToTP app on an offline device, like an iPod touch.

So:

- 1st.) ToTP on offline device (most secure, most expensive, most difficult to learn, hard to use),

- 2nd.) 2nd email (can be most secure, cheapest, easiest to learn, easiest to use), and

- 3rd.) SMS (least secure, mid-expensive, mid-learnability, mid-usability).

Why didn't we all default to 2nd email then, instead of SMS as a paradigm? Actually, was used, and still used by Gmail from the beginning (even in conjunction with ToTP now)...

My guess is the most common attacker is someone sitting on a computer in a different country/continent. So:

1) Getting a mobile phone number seems much more difficult than getting an email. It provides some amount of country verification: If a service runs for let's say Danish people, then they can expect the phone number to be a +45.

2) taking over someone's email seems much more easy than taking over someone's phone, since many people reuse same password everywhere, then if you already have the password of the service requesting the OTP, good chance is that you also have the email password. The email address is not hard to find if attacker has password to the first email too. Hoping for security by obscurity (i.e. the 2nd email is now a "secret") isn't great.

3) physical security: without sophisticated attack, SMS can only be received on the actual user mobile phone, even if a phone with no passphrase. "If the phone is stolen" isn't a realistic scenario against a scammer on another continent.

Also from a theoritical point of view: it's a completely different communication channel, so if someone has somehow taken over the first channel (via some malware running on the email client/computer), then they still need to take over second channel. So for instance, if a USPS snail mail wasn't so slow (or you don't need the OTP code right away), even if really insecure, it'd be better than 2nd email, as it follows same benefits as SMS.

I believe I (+ the paper) addressed counterarguments 1-3, so agree to disagree. But...

> Also from a theoritical point of view: it's a completely different communication channel, so if someone has somehow taken over the first channel (via some malware running on the email client/computer), then they still need to take over second channel.

...is a very good point. Although, (without any data to back up this claim), I would think most users with a compromised device have a fully compromised device.

Edit:

> Hoping for security by obscurity (i.e. the 2nd email is now a "secret") isn't great.

To clarify, that's not exactly the point. If the attacker discovers the value for the phone number or 2nd email (through a data breach), then it becomes targeted, which brings us back to the security of SMS vs email (the parent article).

>2. in unionized environments

what is meant by "unionized" here? It doesn't seem to be related to labor unions.

Specifically, in unionized environments introducing new technologies and methods no matter how seemingly trivial creates an obligation for formal job training. Setting up an hour of training for 5k+ people on how to install and use Auth0 is way more expensive than just sending someone an SMS. There is no implicit responsibility to adapt to change.

If an employer wants employees in a bargaining unit to use their own mobile devices and install a TOTP app on them, employer has to pay, and then the responsibility for it working needs to be established. In normal environments, you just say "we use this here," and users figure it out. If it's organic bottom-up adoption based on the option, it works, but if you impose a change, it creates admin overheads.

I am not sure which countries you relate to, but requiring pepole in France to use their private phone for work is simply impossible.

That's too broad a generalization. I am aware of unionized environments where the employer uses MFA and expects the employee to bring their own device, and the user is expected to read the online KB documentation in lieu of formal training.

tl;dr -- unions aren't all alike, and don't all bargain over the same issues.

Agreed with this analysis.

Trying to teach my parents now to use a Authy, Google Auth, 1Password, LastPass is pretty much a non-starter. I'd be getting calls every other day.

SMS 2FA allows my parents to considerably shrink their attack surface without a high barrier to entry.