The Google Authenticator app isn't the only app that can be used to generate TOTP tokens, even though many sites directly refer to it. Anywhere that you are given a QR code to scan you can use any TOTP app you'd like. I use Authy personally because it allows me to back up my TOTP tokens behind a master password and access to my phone number, so in the event my phone is lost or replaced I'm able to restore 2FA access by going through the process to configure Authy again and re-enter my master password from another password manager.

This is just a softer layer of security to slow down less sophisticated mass signup attempts.

Google may very well eventually phase out TOTP, under the justification that it is not as secure, but I would be shocked if they ever retire the highly insecure SMS verification.

Why? I hope they don't, as I'm relying on my password manager to emulate a hardware token so I can finally log in to websites without needing a username/password.

At its core, FIDO2 is an authentication API, so the site can ask your browser to authenticate you (in whatever way the browser wants). If that's "talk to the password manager to authenticate the user using some fancy cryptography", why does the authenticating site care?

I'm looking forward to the day when my password manager only has one credential in it, my soft-FIDO2 private key.

> Why?

Likely not in the same of security, but as an extra speed bump for automated account creations.

The easier it is to create accounts in automated ways en masse, the more likely that system can be abused.

If you require SMS authentication, you can use that telephone number as a means to limit accounts being generated.

If you can restrict software emulating hardware, you're similarly increasing the barrier to entry to require hardware tokens too, increasing the cost of creating accounts used for fraudulent activity, and reducing the lower hanging fruit (e.g. spam) from being as profitable.

If you require SMS authentication, you can use that telephone number to personally identify the individual. Privacy invasion justified in the name of security.

You use self signed certificates all the time with SSH. If you haven't seen an SSH key before, you don't fall back to telnet.

If you stop to think about it, is incredible how much effort they put into forcing you to use the latest browser, and not trust self signed certificates. It is far easier to root your device and patch your kernel than it is to use an older browser.

Yes, it is a highly effective but clumsy heuristic to detect abuse. But I am convinced that they may have other incentives as well.

The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

Which is why LetsEncrypt came to be: it provides at least some chain of trust without any extended validation, which is a bit extra on top of self-signed certs.

But again, should you watch out more than if you were using HTTP? Does your browser make you opt in to connecting to every HTTP site on an open wifi network? What about an HTTP captive portal on an open network?

I have not heard a good argument for the current behavior with self signed certificates that justifies the behavior of completely unencrypted connections.

The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website. Perhaps leave the scary warnings for submitting something over an self signed or unencrypted connection.

If users expect to be "safe" when on a secure site, without them understanding intricacies of certificates, self-signed is counter productive.

There are certainly improvements to be made to the experience, but none of that can explain all these nuances in a way a temporary visitor will read and grasp.

OTOH, it's easier to teach them "HTTP unsafe, don't type anything private".

If it can't verify the website, the connection is not "safe from third party attacks".

There are legacy concerns that factor in here, where HTTP was the default, and HTTPS was a costly alternative.

Changing defaults can be expensive.

Out of the box, you will get a lot more resistance for using a self signed certificate than bare HTTP. At the very least, self signed certificates should be in the same security context as HTTP.

Our devices should opportunistically use encryption, even if validation is not available.

I had a client that wanted to use an Android tablet to monitor IP cameras on his local network, and it was virtually impossible to use the TLS on zeroconf .local domains.

The official solution is to rely on the underlying network for security. Even though the webservers on devices and our browsers have TLS support.

A random thief stealing my laptop would have to:

1) Bother

2) Break my hard disk encryption/know the password

3) Break my password manager encryption/know the password

I think that's hard enough for someone wanting to get into my email. I use a separate hardware key to secure my domains, and that's about it.

What's the attack vector you are protecting against that a good, non-reused password is not covering?

Still, when you've got access to your password manager (to get your password and TOTP token too), you've got access to a trusted device too.

And there is still an option for anyone (including shoulder surfers) to type in your password+token a bit faster than you so they get in: nobody bats an eyelid for getting reprompted for another TOTP token.

You are also vulnerable to someone stealing your password manager password in this manner, especially with a cloud one (which is what most businesses require).

As a conclusion, it does grant you some extra protection against using password only, but when on a separate device, it's really another dimension.

I now have a weekend project....

[1]: https://keepassxc.org/docs/#faq-security-totp

[2]: https://f-droid.org/en/packages/org.shadowice.flocke.andotp/

I first heard about Authy when it was recommended to me by coinbase but sometime last year coinbase forced me to change to Google authenticator.

Any access is easily "phished" with pliable people (which is not necessarily a set of people, but also a question of timing and circumstances: everyone is sometimes more or less pliable): "please log in with your U2F device, download that document and upload it to this URL https://your-company-confidential.s3.amazonaws.myurl.com/, before we can reinstate your access to company systems".

The advantage of U2F is that it isn’t phishable. You can only sign the message for the pre enrolled URL.

Yes, you can still fall for more elaborate instructions but you cannot simply give the attacker your credentials through a normal looking flow.

I also disagree it's that far fetched to get people who'd do that to also do whatever else you want them to.

And while SMS swapping is miniscule in comparison, the big difference there is that there is no signal at all that you are under attack. With phishing, there is no way you are not feeling something is at least a bit off, so you know to check soon after, even if you've been compromised.

After this happens it takes you to a “something went wrong” page and has a link back to your real bank website.

With U2F this impossible because you cannot sign a message for bank.com when visiting evil.com.

They're probably hiding the TOTP option because the backup story for Google Authenticator is really poor. If you lose your device, you lose access to all of the accounts you had set up 2FA for with Google Authenticator. Of course, there are other TOTP apps that are better in this regard, but Google is unlikely to promote those because then they'd lose some control over the authentication flow.

[1] https://github.com/andOTP/andOTP

https://github.com/beemdevelopment/Aegis

Though now Google Authenticator supports transfers, there is less of a need.

But I still enjoy using andOTP.

(I am, somewhat shamedly, not yet a user of TOTP 2FA, although I will have to become so soon because of various platfrom and organizational requirements, and am trying to figure it out, and finding it challenging).

What are the options/ways that other TOTP apps handle this better, what are my choices here?

The way to handle this correctly is to have backup options. This can be a second device or a printed sheet of backup codes. I’d wager that few people actually do this, though.

E.g., when I create an account at a site that uses TOTP I scan the QR code on both my phone and my tablet.

(Actually, I scan it twice on each device, using two different TOTP apps. That way I'm covered if one of the apps stops being supported).

If you don't have all your devices available at the same time, or you want to allow for the possibility of adding a new device later, you can simply save the QR code. When the site gives you the QR code, take a screenshot and save that in some secure fashion. I save it as an encrypted PNG file.

To add a TOTP device later view the screenshot and scan the QR code.

Most sites that give you a TOTP QR code have an option to get the code in text. As an alternative to (or in addition to) saving a screenshot of the QR code you can ask for the text code and save that. Securing a text file might be more convenient for some people than securing an image file, although using the text code to set up a new phone or tablet likely won't be as convenient as using a QR code.

I guess you need to keep these QR codes/texts as carefully/securely as you would any password....

This is all a lot of work, trying to figure out how to adjust to this world of 2FA.

You need the password every time you login to a site, so you need to find a way to securely store passwords that also allows easy frequent access to the password.

You only need the QR code when setting up a TOTP application on one of your devices which generally will only be once per device and then once whenever you replace a device. You don't need frequent easy access and so can pick a storage method that is optimized toward ease of initial storage.

For example if I've just signed up for site example.com and I've saved a screenshot of the QR code in example.png, I'd do this:

  $ gpg -ear tzs@mydomain example.png
  $ mv example.png.asc ~/OneDrive/totp-recovery
  $ rm example.png

A more user friendly cloud solution might be Authy that others have recommended.

You can actually do backup of your keys (encrypted).

Also they reverse engineered the steam Authenticator, so one less app to have on my phone.

[0] https://getaegis.app/

* TOTP (and SMS codes) can be forwarded, so you can be phished/duped into entering credentials on a spoof website. FIDO prevents this.

* TOTP (and SMS) may be grabbed from your phone by malware. This is harder with FIDO as it requires a physical button press.

* TOTP requires substantial user knowledge to use correctly. FIDO also has usability issues (have to keep your key with you, endless USB-A vs USB-C issues) but maybe they believe its better.

Even so, non technical people get very confused by this stuff. As the CTO, I enforce 2FA for all of our stuff. But it continues to be a support headache when we have new people joining.

I'd love for this to be solved in a more user friendly & standardized way. So, I can understand why Google moved away from TOTP as the main way to do 2FA. It probably caused a lot of support overhead for them.

Hardware tokens have the same issue. Nice for techies but too hard to deal with for normal people.

Google has been mainly prompting me on other devices rather than asking for my TOTP code, however.

Allows you to import and export to csv; ios app also has automated icloud backup if you're so inclined.

The fact that Google doesn't give him the option, presumably.

>We recommend you sign in with Google prompts. It's easier to tap a prompt than enter a verification code.

A bigger security/privacy issue with U2F is that you cannot use it with javascript disabled.

Honestly, the alternatives are worse. For U2F keys, you need to remember to bring your dongle with you, it has bad support on phones/mobile devices, some machines lock down ports, and there's a not-insignificant cost to buy.

You might correctly call that concern more focused on CYA of the the firm itself, but I think that's not the worse thing in the world, and the underlying crypto primitives certainly played a role here.

Meanwhile: WebAuthn (nee U2F) was literally introduced as an anti-phishing tool --- not as a database protection technology. They did U2F because people kept getting phished with code-generator authentication. The problem with TOTP is that it doesn't have a mechanism to authenticate the site asking for the code.

If you can trend towards public key based schemes there's real benefits from the IDPs prespective. Yes TOTP wasn't designed to help here, but from the IDP's perspective that just means that you should gently shift users to 2FA schemes that do provide those semantics. And U2F/FIFO is not the only other option here, just the only one that can be implemented totally in browser for the client. Duo's phone push notifications are public key crypto under the hood for one example.

The calculus is different if you're just a regular website, but the question was pointed at Google, an IDP in their own with many forms of public key schemes implemented.

The benefit of using TOTP at all far outweighs the insecurity of storing it on the same computer. And it is so low effort, I use it everywhere possible.

I have a simple script that takes a screenshot, uses zbarimg to extract the single line otpauth:// string, and appends it to my pass password database[1], which then hooks back into my browser. I somehow don't think I would bother with a hardware key for my BestBuy.com account.

Besides, my password db is itself is encrypted with GPG, and GPG can use a hardware token to be unlocked, thereby giving you more flexibility and transparency, while still benefiting from a token.

Developers can't know what configuration users have.

[1]: https://www.passwordstore.org/

Point of something being a second factor is for it to be something physically distinct from the first factor, and something different in the "something you know, something you are, something you have". As long as you keep your TOTP device and password manager separate, they provide all the guarantees a second factor should.

As a bonus, they also provide one-time use tokens (both HOTP and TOTP, though HOTP is more susceptible to pre-generation of tokens to be used later), thus protecting against eavesdropping and people looking over your shoulder (or recording you).

As such, I don't buy the argument for TOTP not being a second factor auth at all.

And there are children comments here talking about how it's fine, they keep their TOTP keys in the same password database.

Yes, there are comments of people using them here that way. At my previous job, even a security IT guy did not find that an issue when I brought it up how people automated 2FA for CLI scripts. In that case, they are not even 1.5FA, they are strictly 1FA password-authentication (jumping through a few hoops to get all "components" of a password, but it's a single password protecting access).

If they are separate devices and you don't really remember your key, they are hardly something you know, IMO, so I disagree there.

In a sense, you could also extract the base cryptographic key of any hardware token (or the producer of the token might have it), and it's also "something you know", which is why I disagree. It's just trivial to extract this key for TOTP, but extraction is a separate step IMO.

If you want to do it with a protocol that enables signed messages and other stuff then the UX cannot be “type in a few numbers.”

Why not?

With TOTP, you type in a short code. The server needs to also be able to generate this code so they can verify that your code is correct. If it only has the public key then it must be able to produce the tokens to login as the user.

If you want a more complex setup where the public key can only verify that the code is valid but cannot be used to create valid codes then the codes themselves (and the protocol) become considerably more complex and aren't going to be managed by a "type six digits into a web form" UX.

I also don't think this really matters in a major sense. If somebody pwns the credential database then continuing to rely on authentication to prevent further harm is a fool's errand. "The adversary only got to extract the credential database and achieved nothing else" is not an especially common scenario today.

(I.e. they have the option: use their personal phone, or carry this Yubikey.)

Privacy invasion in the name of security. TOTP doesn't offer this and is clearly to be discouraged. Unless you accept the privacy invasion, they really don't want you to have an account.