Put a plan together for the "house burns down" scenario.
With U2F I need to enroll multiple tokens and keep some off-site. So what does this entail? I keep maybe 3 tokens, two on-site that I add the new account to, then on a regular schedule I rotate one off-site and bring the third one on-site and go back through and add it to any accounts I've created in the meantime? The whole process is a pain in the ass, and not all sites allow multiple devices to be registered (e.g., AWS). And new accounts are still vulnerable during the time between registering and rotating the third key on-site.
With TOTP you can... just sync your TOTP database. Some apps such as Microsoft Authenticator do this on their own. Personally, I put all my TOTP secrets into a Keepass database and sync it off-site with Nextcloud. There is no way for the site to limit how many devices I enroll so it's easy enough to create as many backup devices as you need. If you're really old school, you can print the secrets and put them in a fire safe.
FWIW, I have several yubikeys. I primarily use them as a secure store for TOTP secrets and to store a SSH key (generated off-device and backed up), not for webauthn. It's just too annoying to deal with in a way that ensures I don't lock myself out of an account.
Every modern TOTP app is cloud-synced, so I'm not sure why people are saying it's "a pain in the ass if you lose your device."
Heck, most modern password managers (e.g. 1Password, LastPass, etc.) are also TOTP, and help you fill the TOTP token (usually by putting in on your clipboard) at the same time they autofill the password.
> It is also weak to phishing (extremely common) but adds protection against SIM-swapping (comparatively very rare).
Sufficient paranoia / user training is enough to protect against phishing. (Especially for services where the only "users" are the extremely-paranoid IT admins themselves.) But nothing can really protect you from SIM-swapping, save for not allowing services that use single-factor SMS recovery to ever know your phone number in the first place.
I've got a few services that only support Symantec VIP, which does not allow you to extract secrets.
> Sufficient paranoia / user training is enough to protect against phishing.
Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.
See https://www.reddit.com/r/1Password/comments/8yey6y/how_do_i_...
(PITA, I know, but running little auth gateways like this is part-and-parcel of doing security for an org.)
> Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.
It's almost always the service's fault for being designed in such a way that its real async user interactions are indistinguishable from phishing. You can't train a user to distinguish X from X.
• It's hard to train users to not forward TOTP tokens sent to them to someone else, if the real service will text or push-notifies the user their TOTP token "at random" (i.e. because the attacker tried to log in.) But if the service never does that — if you always have to go and fetch the token from your TOTP app — then you can just tell the user that the only time they are to go do that, is right after they've typed their username and password as part of logging in themselves; and that anything else is a phishing attempt.
• It's hard to train users to not type their username+password into phishing login pages, if the services you use constantly send you emails containing deep links. But if the service never does that — if the service always tells you to go your browser and navigate to the site yourself — then it's easy to teach users to never trust a login initiated through an email.
Security, in this case, is less about "good security hygiene", and more about priming/expectations. And because of that, the practice of being an IT admin for such an org, is a practice of picking services, or negotiating with services, to ensure that the service is following secure workflows when dealing with your users, so that your users can be trained.
> It's hard to train users to not forward TOTP tokens sent to them to someone else, if the real service will text or push-notifies the user their TOTP token "at random" (i.e. because the attacker tried to log in.) But if the service never does that — if you always have to go and fetch the token from your TOTP app — then you can just tell the user that the only time they are to go do that, is right after they've typed their username and password as part of logging in themselves; and that anything else is a phishing attempt.
A phishing attempt will do precisely this. You get a fake login page, type in your creds, and then you get a fake TOTP page.
> It's hard to train users to not type their username+password into phishing login pages, if the services you use constantly send you emails containing deep links. But if the service never does that — if the service always tells you to go your browser and navigate to the site yourself — then it's easy to teach users to never trust a login initiated through an email.
In a prior life I did some research on phishing. It is embarrassingly easy to fool even professional security researchers. Nobody is capable of consistently preventing phishing by using their own eyes and brain.
While TOTP contains a bypass (phishing) SMS contains an additional vulnerability.