10 ms·

Ask HN: Is Google phasing out Authenticator/TOTP?

51 points by prometheon1 5y ago

I use TOTP for every site that supports two-factor authentication. When setting up 2FA for a new google account, I can choose: SMS/call, security key or google prompt. I don't have a security key, I would prefer not to log into google with my work account on my phone, and I would prefer not to be susceptible to sim swapping. Is TOTP less safe than SMS/call? Interestingly google's own Authenticator TOTP app still exists, but apparently you can't use it to set up 2FA for a google account anymore: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2 https://play.google.com/store/apps/details?id=com.google.and...

Symbiote 5y ago
We issue security keys to staff who don't want to use a personal phone for work. (I.e. they have the option: use their personal phone, or carry this Yubikey.)
nullbytesmatter 5y ago
I always store the secret key for TOTP before I use the QR code. I have a command line app I wrote that can generate OTP codes using the same secret key, so as a back up I can always generate codes with my desktop or phone.
mcwhy 5y ago
you can add a security key (real or emulated one) then add TOTP and after remove the security key
- 0x6c6f6c 5y ago
  Yes, but why not just offer it in the first place? I had the same impression when I had to jump through those hoops
trulyrandom 5y ago
You can set up 2FA through one of the other options first. After that, TOTP should be available as an option as well. After setting TOTP up, you can remove the other one. 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.
- mmastrac 5y ago
  I dislike how the only way to get TOTP codes off a device is by rooting. I had a half dozen codes that I had to dump from the sqlite db when I first used authenticator.
  - krmboya 5y ago
    I use andOTP[1] installed via f-droid. You can easily get a backup file with your codes. [1] https://github.com/andOTP/andOTP https://github.com/andOTP/andOTP
    - simonmales 5y ago
      This! Though now Google Authenticator supports transfers, there is less of a need. But I still enjoy using andOTP.
    - aorth 5y ago
      Just FYI, it's possible to backup your codes on Android using Aegis too. No root needed. https://github.com/beemdevelopment/Aegis https://github.com/beemdevelopment/Aegis
  - cian 5y ago
    Thankfully this has been fixed. You can now choose "Transfer accounts" (from the menu in the top right corner) to copy everything to Google Authenticator on a new (or backup) phone.
timcosta 5y ago
SMS is not reliable for 2FA, it's trivial for a determined party to sniff SMS messages. TOTP is the best way for typical users to do 2FA, as most people wont have a Yubikey or anything like that. Google Prompt is the equivalent of iCloud's cross-device prompt where you must allow the action from another device that's already logged in to the account. 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.
- sneak 5y ago
  Smartphone secure enclave U2F is the best for users. TOTP is still easily phished.
  - necovek 5y ago
    I think phishing is an entirely different matter. 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/ https://your-company-confidential.s3.amazonaws.myurl.com/, before we can reinstate your access to company systems".
    - UncleMeat 5y ago
      It isn’t a different matter. It is the core matter. Phishing and stuffing completely dominate the actual attack space. SIM swapping and other theft of SMS messages is tiny in comparison. 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.
mmastrac 5y ago
Tangentially related but I made sure to store all of my TOTP codes in a secure, offline location so that I can quickly migrate my 2fa app to a new phone by generating QR codes. Google has been mainly prompting me on other devices rather than asking for my TOTP code, however.
monocasa 5y ago
TOTP is falling out of fashion because the underlying crypto component is just a plaintext secret that is distributed over the Internet and stored unhashed in a database, probably right next to the password hashes. There's a real argument too be made that it's not a real second factor but instead more like 1.5FA.
- c0l0 5y ago
  Cool; when are we going to get rid of the "API key" then?
  - monocasa 5y ago
    An API key is basically 1FA, not really sure why that's relevant.
- deleted 5y ago
  [deleted]
- briHass 5y ago
  The storage of the secret on the server side isn't really relevant to the major wins that TOTP provides. A well-done implementation stops keyloggers and shoulder surfers, and for many people that aren't using password managers, it does add a significant level of security, without greatly inconveniencing the user. 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.
  - monocasa 5y ago
    U2F keys aren't the only other option. Treating phones as a always connected hardware dongle with an app is another option. There are others as well. Hardware tokens talking U2F/FIDO are just the only standards compliant option that can be implemented totally in browser.
- BoardsOfCanada 5y ago
  Had to look it up and you're correct. Why on earth isn't it based on public key cryptography?
isoprophlex 5y ago
I'm irrationally quick to hate on anything Microsoft touches, but for TOTP their Authenticator app is very good. It holds my google TOTP, amongst others. Allows you to import and export to csv; ios app also has automated icloud backup if you're so inclined.
sixhobbits 5y ago
Off topic, but I moved from Google Auth to Aegis[0] recently and Aegis is so much better in every possible way. [0] https://getaegis.app/ https://getaegis.app/
- mshook 5y ago
  And it's GPLv3 and on GitHub. And yes, when I migrated, it offered features G Auth didn't have, haven't checked since...
johndfsgdgdfg 5y ago
Please use Microsoft Authenticator instead: https://www.microsoft.com/en-us/security/mobile-authenticator-app https://www.microsoft.com/en-us/security/mobile-authenticato....
hpaavola 5y ago
I'm sorry but what makes you think Authenticator can not be used while getting 2FA in use with your google account? That link does not show anything like that to me. And I used it to set it up about 2 months ago.
- stavros 5y ago
  > I'm sorry but what makes you think Authenticator can not be used while getting 2FA in use with your google account? The fact that Google doesn't give him the option, presumably.
Belphemur 5y ago
I replaced long ago the Google Authenticator by Aegis on Android. 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.
- crtasm 5y ago
  I'd never thought to check until now, the AndOTP app can also do Steam.
stavros 5y ago
I find it interesting that the 2FA methods it gives you are non-anonymous: SMS has a phone number, security key has a hardware ID, and Google Prompt has your IMEI/phone ID (and maybe number?) too.
- sneak 5y ago
  Security keys hardware IDs are either not accessible to applications, or non-unique, for this reason. A bigger security/privacy issue with U2F is that you cannot use it with javascript disabled.
necovek 5y ago
Last I've had to do this (last November): for Google itself, you need to set up SMS 2FA, and then you can add an additional TOTP device and remove the SMS 2FA. A bit annoying, but worked for me for my work account.
jillesvangurp 5y ago
I usually point people to Authy. Nice app and alternatives are available of course. But more importantly they provide nice guides on how to set up 2FA for various websites. Including Google/gmail: https://authy.com/guides/googleandgmail/ https://authy.com/guides/googleandgmail/ 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.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
tim333 5y ago
I don't think they are phasing out Authenticator - I still use it. However for your Google account they say: >We recommend you sign in with Google prompts. It's easier to tap a prompt than enter a verification code.
advisedwang 5y ago
I haven't seen anything indicating TOTP is being phased out, but there are several reasons Google may be driving people to Security Keys (aka Webauthn, FIDO, u2f): * 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.
GianFabien 5y ago
I configured a gMail account for 2FA yesterday with Google Authenticator. Had no problems.

unqueued 5y ago

As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. I believe they can use attestation keys to do that. 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.

stavros 5y ago
> As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. 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.
- necovek 5y ago
  If your password manager has control of both your password and your "2nd" factor auth, it defeats the purpose of it being a 2nd factor. You are still protected from your password hash being stolen from the target website, decrypted and then used for log-in, but if password hashes were accessed, potentially a bunch of other stuff that you'd care about is too, so that's a somewhat moot point. But someone stealing your laptop and getting access to your password manager gets access to your 2FA too. Making it not a "second" anything: it's akin to using two passwords for log in to a single site and keeping them in the same place. Physical separation of the two authentication factors, thus, matters. That also means that you should not have your password manager on the phone, or at least only have a separate one: ideally, password managers would integrate between desktops and mobile devices to pass short-lived access to passwords for Oauth/OpenID Connect auth instead. Yeah, bridging convenience and security is a long standing nightmare of a problem to solve. :)
  - stavros 5y ago
    Yes, I know all that, and that's fine. I'm not looking to solve the problem of authenticating so I can launch nukes, I just want people to not steal my Twitter account. 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.
    - necovek 5y ago
      That's fine, the only question is why use 2FA at all? What's the attack vector you are protecting against that a good, non-reused password is not covering?
      - stavros 5y ago
        Keyloggers, stolen password databases, MITM, shoulder surfers, interception.
        necovek 5y ago
        Yeah, that makes sense: I brought up stolen password hashes, but I generally disregard keyloggers/MITM/interception because I usually use trusted devices and network encryption (HTTPS), but not all sites do, and I can see how people might be forced to use untrusted devices. 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.
- oarsinsync 5y ago
  > > As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. > 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.
  - jqpabc123 5y ago
    If you require SMS authentication, you can use that telephone number as a means to limit accounts being generated. If you require SMS authentication, you can use that telephone number to personally identify the individual. Privacy invasion justified in the name of security.
- unqueued 5y ago
  Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate? 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.
  - oarsinsync 5y ago
    > Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate? There are legacy concerns that factor in here, where HTTP was the default, and HTTPS was a costly alternative. Changing defaults can be expensive.
  - jsnell 5y ago
    Chrome has been marking HTTP URLs as "not secure" in the URL bar for like three years.
    - unqueued 5y ago
      The current implementation is idiosyncratic. 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.
  - necovek 5y ago
    It's been a while since I used self-signed certificates, but experience used to be just about right. You hit the page and browsers throw a big fat warning. You add an exception, basically acknowledging that this is a certificate you trust (exception is for the cert, not any cert on this domain ever), and as long as the certificate doesn't change, your trust is at the same level it was on the initial load of the page. 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.
- hnlmorg 5y ago
  I'd be interested to know more about how you use your password manager to emulate hardware tokens
  - stavros 5y ago
    I don't currently, I meant more in a "I'm hoping they will implement this".
    - hnlmorg 5y ago
      Ahhh. I wonder if this is something I could cobble together with a few open source components. I now have a weekend project....
pinephoneguy 5y ago
It has always, from the very beginning, been possible to emulate hardware tokens.

UncleMeat 5y ago
The backend needs to be able to produce the same code that you produce. If somebody could do that with a public key then you’d need to keep the public key a secret. 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.”
- BoardsOfCanada 5y ago
  I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improvemebt on the way it currently works.
  - UncleMeat 5y ago
    If the public key needs to be a secret then it is the same as it is now. If the attacker obtains either secret they win. The whole point of asymmetric crypto is that the public key doesn’t need to be kept secret.
    - BoardsOfCanada 5y ago
      Maybe I didn't express myself very well. The server stores the public key, instead of the current symmetric secret. So the new "secret" is the public key. It could be published of course but there is zero point to do so. So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user.
      - UncleMeat 5y ago
        > So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user. 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.
        BoardsOfCanada 5y ago
        Yeah you're probably right.

tptacek 5y ago

I don't think there's any validity to this. TOTP is falling out of fashion because it's not phishing-resistant, and, more importantly, because it has poor UX for ordinary users. This "plaintext secret" stuff has nothing to do with it.

monocasa 5y ago
I mean, I was a engineer that participated in those discussions when I worked at an IDP firm. The concern that if we got popped and the password database was leaked somehow, that with TOTP the attackers had everything to start logging in as users who had weak passwords but with public/private schemes they didn't. This was a very real concern that affected preference for public/private schemes (which included hardware tokens), and engineering effort to decrease the UX burden of hardware tokens specifically. 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.
- tptacek 5y ago
  This doesn't even make sense as an objection. If you get popped, attackers are going to log in with whatever credentials you don't revoke. You're simply going to revoke all your 2FA credentials; retaining them, no matter what scheme was used to store them, would be malpractice. 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.
  - monocasa 5y ago
    Yes, you would revoke them as soon as you realize, but until you realize (and practically there's generally a delta there for a successful attack) in public key schemes of 2FA the attacker doesn't have enough to login as those users since they only have those user's public keys. For TOTP they very well might have everything they need for weak passwords. 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.
    - tptacek 5y ago
      The question is why TOTP has lost favor. The reasons are that it has poor UX, and that it doesn't authenticate sites. That's pretty much it.
      - monocasa 5y ago
        And I'm saying that as a former engineer at an IDP, the shape of the crypto played a major role in the forms of 2FA we favored, causing us to specifically de-emphasize TOTP in favor of public key schemes. 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.