Downsides of Google Authenticator | Hacker News Reader

Downsides of Google Authenticator

zdnet.com

188 pointsLinuxBender137 comments

Strongly disagree with the premise of this article:

- Passcode or biometric locks on an app are a gimmick and offer negligible value.

- The keys not being backed up or or synchronised across devices is not a bug, but a feature. You're supposed to keep offline backup keys. Any sort of synchronization feature adds a ton of attack surface.

- In particular, Authy, LastPass and 1password have a giant attack surface compared to a simple app like Google Authenticator. They also rely on centralized services and if you also keep your passwords in there, you eliminate the whole point of two factor authentication.

- One important risk with authentication apps is compromised updates, and Google Authenticator has a very low risk of this since it's backed by Google's strict security processes.

What you should actually do is to move to U2F/WebAuthn and pester any of your service providers that do not offer it. Yes, if you need to replace a token, you'll have to go through all accounts and change it. There's is absolutely no way to prevent this without compromising on security.

Here’s the thing. I consider myself fairly responsible but I’ll bet I’m far more likely to lose my phone than it is that my Authy and Dashlane credentials are both compromised, which are my pw manager and Authenticator app. You have to choose your risks and for a lot of people an authy like feature is much safer overall than GA.

All my 2FA codes are backed up. On paper. I have a physically-secured cache of the QR codes which can be pretty quickly imported into a new app.

Do you trust the security of your printer when you print codes? They are historically one of the biggest attack surfaces.

Are you referring to network-enabled printers phoning home?

My 15 year old Brother doesn't have that capability... So on that front, a printout of QR codes is more likely to be compromised by the paper itself being left out somewhere.

I’m not the same person, but anecdotally I’ve been using an ancient printer for years. I’d like to think it’s quite secure. Only works via usb, no wifi or anything complex. The only way I could get it to work is in Linux where I assume the drivers or however it happens is open source. As far as I know the printer is as dumb as a rock.

Worst case, i doubt it would be that difficult to hand draw the qr codes on graph paper. Would be quite tedious, but they should be error correcting to some extent.

What's your threat model? Security researchers or nation-state level adversaries might theoretically be able to tap your printer and parse it for things that look like codes, but if you're receiving that level of expert human attention then you're probably already compromised in one of 1000 other ways.

The huge majority of people don’t have nation state threat models.

If you are worried about that then using a desktop computer in the first place is a bad idea.

I mean, I think it's a lot less likely that someone compromises my printer which is behind all of the same network protection measures as my PC, scours it for previous printouts of QR codes (if it does retain them), to identify what account they can potentially hack... than that they compromise a 2FA cloud service directly and log into all my accounts.

What's the threat model here? If the CIA is in my home network, I'm sure they can get into my email account too.

What happens when you're traveling? What if some combination of your wallet, laptop, paper files or phone are stolen or destroyed by fire or water?

Essentially, what's your backup plan so if the very worst happens when you're in the middle of nowhere you're not completely locked out?

It's not hard to come up with scenarios that get you locked out for longer than expected regardless of your auth set-up.

e.g. "What if I'm traveling, I lose my phone, and the country I'm in blocks internet access to my 2FA service?" "What if I'm traveling, I lose my phone and my wallet?" (In this case, even if you use a syncable 2FA service - how will you pay for a new device to access it without your wallet? You have a different problem here, that likely involves going to an embassy and/or relying on friends & family!)

The question is, (a) how _likely_ are those scenarios? And (b) how much risk/damage/pain do they cause?

If I'm traveling, I'm fine unless I lose my phone. If I lose my phone, then I guess I can't sign in to some/many things until I get back. If I lose my phone AND my wallet and I'm not at home, I'm probably more worried about getting my ID cards and bank cards replaced than accessing certain websites. If my house burns down with my phone, wallet, and backup cards inside, I'm probably just thankful to be alive.

If I'm traveling, and I lose my laptop, phone, and wallet, I really hope I can't restore access to my 2FA codes! Because if I can get access to my 2FA codes somewhere else in the world without those things, so can an attacker!

I see people say this a lot in the tech community, but it’s a preposterous expectation that regular users would be doing something like this. MFA needs to usable by everyone, not just the tech elite.

MFA is a power tool for extra security. It deliberately sacrifices usability and integrity for security. If you want something more usable, you don't want MFA.

Really though, I think "one-time passcodes" is the wrong escape hatch because it is actually just password auth, not a second factor. The way it ought to be is that you hook up multiple devices. (e.g. like having both a phone Authenticator app and a USB key.)

Or, I keep using single factor because services MFA implementation sucks tremendously, and as per service agreements service is liable in any security compromise case.

Frankly, most of MFA is security masturbation, is nowhere near to being a real solution, not even a real problem. Its just neat from a technical standpoint (if done well, which nearly never happens).

A minimum of 2 registered u2f keyfobs, that's all you need to make it usable and safe. Nobody does it, and trusts people either backup their otp codes or never lose or break phones. Ridiculous.

MFA is always better than single factor. At the very least it makes drive by/automated attacks significantly harder. Everything you read about SIM jacking and the like is at bare minimum, much harder than hacking your password.

From a users perspective, MFA is nearly never better than single factor. Attacks are services responsibility anyway.

At some point something has to give though. Security and convenience are constantly at odds with each other. My opinion is that it's far better to convince people that it's worth the inconvenience rather than watering the security down to the point where it's basically pointless. And if they take the consideration that the extra security isn't worth it for them, then that's the choice they make.

I have copied all the 2FA strings in a separate keypass database, with a different password, only in my memory.

I also went through writing a simple javascript page to import all those keys to Google Authenticator via totp:// protocol. It takes a csv of all strings, and spits out the html links with totp://protocol. All using local storage only. So whenever I change phone, I paste the csv from keypass to google keep (pretty safe), open it on the new phone, copy it & paste into my html5 app, and click each link and it auto adds itself to Google Authenticator. Then I select all text in Google Keep and delete it.

A Yubikey is what you are looking for.

https://www.yubico.com/

Paypal though has no backup codes...

Take a look at SAASPASS Authenticator & Password Manager. You can use them separately or integrate them for extra convenience and autofilling options. The desktop browser extension can autofill both passwords and Authenticator codes and on mobile with iOS 12 onwards with autofill capabilities.

As long as you use encrypted backups with iPhone, your GA keys are backed up and you can restore a new phone with them also.

GA keys are not in icloud backups. You mean local “usb” backups?

They are definitely in local backups (note that I didn't say iCloud), but I believe they're in encrypted iCloud backups as well, as I've done recovered phones with GA tokens from an iCloud backup before.

Only the keys that specify they may be backed up. The ones that don’t are not included, not even in the encrypted backup.

Last time I did a backup/restore between iphones using encrypted itunes usb, GA came up empty. Had to go through painful account recovery / lost 2fa procedures on a dozen accounts. Now I use "OTPAuth" instead. Even comes with an Apple Watch app!

I second every part of this comment. I ran into the same issue migrating GA to a new phone, none of my keys went with. Very frustrating experience.

I also switched to OTPAuth, great app, provides encrypted backups and switching to a new phone was seamless. Would absolutely recommend over Google Authenticator.

I feel you're letting perfect be the enemy of the good. The baseline isn't centralized 2FA. The baseline is not using 2FA at all. While you may be willing to accept usability trade-offs associated with the lack of synchronization, a lot of people aren't. We shouldn't let better security be accessible only to tech-savvy people.

This article isn't an advertisement for centralized 2FA. It is an argument that you should ditch Google Authenticator for a centralized 2FA app. Therefore the baseline is people who already have 2FA enabled.

I agree with this comment completely. Adding a biometric lock would turn it into 3FA.

Not sure if HN allows to plug your own apps, so please forgive: I made an app a while ago that aims to replace Google Authenticator for some of the reasons mentioned: it allows to back-up and transfer tokens without creating a large attack factor. Not having sync is a feature in this case as well. In fact, the app does not even have the internet permission enabled, so it utterly unable to phone home. Transferring backups does require a biometric lock.

It is also entirely free, so I'm only posting this out of pride of my own work: https://play.google.com/store/apps/details?id=com.pixplicity...

Thanks for sharing I will take her back although should I trust a random app from hacker news with my passwords?

Biometric data should be considered identity and not authentication data. They can never be revoked or rotated for one. And who knows how many people have it on file. Not every auth server gets their own « key »

Makes sense. The principle of 2FA is to combine 'something you know' (a password) with 'something you own' (your phone). I guess the biometric lock is 'something you are' on top of that.

> You're supposed to keep offline backup keys. Any sort of synchronization feature adds a ton of attack surface.

I find that a terrible design decision, because now every website has to implement their own backup code flow. PayPal, for example, is one of the most critical applications when talking about authentication, and while they support 2FA they don't give you any backup codes at all: https://www.paypal-community.com/t5/My-Account/Backup-codes/...

Now I cannot synchronize devices, I'm hosed if I ever lose my phone, and I'm still relying on PayPal customer support to do a proper out-of-band authentication. The worst of both worlds.

At one point I was able to use two copies (phone and iPad) of Symantec VIP Access with Paypal. I changed phones and I wasn't able to use the new copy.

However, I was able to set up Authy as a secondary authenticator.

I don't have SMS as 2FA for PayPal.

The offline backup can be a printout of the QR code.

The best available solution is to implement WebAuthn support and allow users to add multiple devices. No backup code, no phishing.

>- Passcode or biometric locks on an app are a gimmick and offer negligible value.

Biometric locks are interfaces that the OS does not expose to users, and that are backed via an HSM. On the iPhone and modern Android, they allow you to envelope encrypt a message via biometrics in such a way that it can only be unlocked from within the app that locked it AND via enrolled biometric signatures. Passcodes are the same, but easier to phish.

It is incorrect to say that they "are a gimmick and offer negligible value".

In this document, they lay out these mechanisms in great detail. Anyone with an interest in security should read this, imo. It's a magnificent "blue team" effort https://www.apple.com/ca/business-docs/iOS_Security_Guide.pd...

Your biometrics are already getting analyzed from all angles somewhere in China just from all the face apps that predict which Disney princess you are. And you cannot change it like a password. So that's why it's a gimmick.

That is not very civil of you. OP is making a very solid point. Consider your threat model first. If you're a high value target, then yes it's probably a gimmick as you're more likely to have a gun to your head. But for other attack vectors that are more automatable and deployed at large (e.g. Trojan Apps), as OP suggests, it is a lot of things, but not a gimmick.

First, shoutout to HN for not blocking my Tor throwaway.

I am someone who would be considered to be a "high value target" since I have had some of these things happen to me and I'm certain they will happen again in the future. I work in a politically sensitive industry where it turns out these things are commonplace.

When I was younger I was always security conscious and took serious trade-offs to maintain my privacy. You could have called me paranoid, but I think I was more excited at the idea of being protected against all of these high-level threats, even if most of them were nonexistent at the time.

While this discipline certainly benefited me later in life, I've realized that I will never again get the chance to reasonably evaluate my threats as "average" and enjoy some of the simpler conveniences of technology that come at the cost of compromising some high-severity threat models. Of course I still think there are a lot of precautions the average person can take to protect their privacy without major trade-offs, but those don't usually include state actor-level threats against your devices.

I wouldn't change a thing now, but when I talk to people who see no reason to take anything more than the average precautions, I no longer think it's "cool" to do anything more than that because I know for a fact I would too if I was in their shoes.

> That is not very civil of you.

I think @trickstra was quite civil in their comment. And they also brought up a completely valid point:

> > And you cannot change it like a password. So that's why it's a gimmick.

Regardless of threat model, not being able to change biometrics makes them very high value to an opposing force. Using biometrics "for the masses" to whom they don't have that completely different threat model practically eliminates their ability to upgrade their threat model since their biometrics have potentially been compromised already. Therefore, it very much is a gimmick.

I'd say the threat model is critical. If your adversary is a state power targeting you personally, you have already lost. They'll just throw you in jail, or worse, until you put your thumb on the button.

If your adversary is a random thief, or the untrustworthy general public, then it works great, and is a significant upgrade from the zero security that most people had prior to the proliferation of biometrics on phones.

You are missing the point - it would be an upgrade, if it wasn't coupled with the proliferation of random apps scanning faces and fingerprints and people randomly giving out their biometrics to anyone. It won't take long before script kiddies will crawl the internet using the latest biometric leak just checking which other services the victims used.

> It is incorrect to say that they "are a gimmick and offer negligible value".

I'm well aware of how the mechanism works.

If the host OS or the app is compromised, it won't help - the attacker can just steal the codes after they're unlocked by the enclave.

For physical theft, it only provides a meaningful advantage if the phone is unlocked. Someone stealing your unlocked phone to get at your 2FA codes is well outside of most people's threat model.

>If the host OS or the app is compromised, it won't help - the attacker can just steal the codes after they're unlocked by the enclave.

If the host OS or app is compromised, then it absolutely helps! The codes cannot be stolen until the user unlocks.

Considering that the most recent iOS jailbreak was not persistent, due to their chain or trust, this is absolutely helpful. It's one component of defense in depth.

In a system with a properly established chain of trust (as ios and android have now), compromising only one component is not enough to ensure complete user compromise.

In your "advanced threat" example, where a fed compromises a device, powering off and then on the device will hopefully put the device into a trusted state again. Aside from the boot0 exploit that nailed ios a few months ago, a few revealed state-level attacks _were not persistent_. Even here, it helps!

>For physical theft, it only provides a meaningful advantage if the phone is unlocked.

These biometric mechanisms are implemented in such a way that "opportunistic" theft (such a as a mugging) yields a positive outcome for average users.

>Someone stealing your unlocked phone to get at your 2FA codes is well outside of most people's threat model.

Aside from the aforementioned compromised host example, which has been a problem on android in the past.... 2FA, sure, that's a bit more esoteric... except... not really. Since 2FA can be used for payments, or other sensitive info, we should probably give users the opportunity to protect against. I work for a personal finance company and we enforce biometrics for a 2nd factor on login to help protect against both the compromised host threat, but also to prevent against spousal, familial id theft (more common than you'd think, sadly). Your familial member may know your passcode, but they will be unable to access your financial data.

I agree with you that it's a good defense in depth measure for exactly the reasons you describe.

Your biometrics cannot be changed nor revoked; they are neither a login nor a password.

They are a weak mechanism against individual targeted attacks, but a great mechanism for herd immunity. It's not perfect, for sure, but it helps raise the posture for the general user in a way that's easy and accessible. That's a win, imo.

> They are a [...] great mechanism for herd immunity. I don't see how, could you elaborate what you mean?

Imagine a leak from a database storing biometric keys, is this a disaster on par with a normal leak? In my opinion it's even worse!

You might say we only use biometrics for a local authentication, but that would limit their application. If you convince people biometrics are great, such database will inevitably be created - what are the chances we store and guard biometrics better than we do with passwords?

Sure, but keep in mind the prerequisites for using that leaked data. You have to either place yourself in between the sensor and the rest of the device or physically recreate the biometric with enough fidelity to fool the sensor. These are both possible, yes, but they’re significantly less trivial than using a password.

This, by the way, still also requires physical access to the device if used for local authentication. And in the event biometrics are used in a physical location (which I’m not personally a fan of, but let’s consider it anyway), there’s often also a human there as well. Your clever mask may fool the sensor, but it probably also still looks like a mask to the guard behind the desk.

Well, an option to export to an encrypted file so that is easy to move between phones is an acceptable tradeoff. Using 1 day pf my time to authorize again all the websites is much worse (and i have to disable authenticator during that period). Sorry, I disagree. For the same reasons passwords are not good, an uncomfortable solution is not ok

> In particular, Authy, LastPass and 1password have a giant attack surface compared to a simple app like Google Authenticator. They also rely on centralized services and if you also keep your passwords in there, you eliminate the whole point of two factor authentication.

1pass user, while I know that it's not as secure as keeping them separated I view it as if someone has access to my 1password vault unencrypted I'm already screwed, but having 2FA coming from 1 tool still protects me from the case of my username/password pair getting leaked or MITMed.

As a LastPass user, my main defense against the possibility of someone accessing my LastPass account is the fact that all of my important accounts have 2FA completely separate from LastPass.

So if someone got a hold of my LastPass master password, they can't access my google account, banking, etc.

I'm curious about LastPass - it's what I use and work in politics.. Their security page says encrypted on device [1] before sending to them? is that not trustworthy or I'm not understanding? or maybe worried about compromised devices (where it's over anyways)?

1: https://www.lastpass.com/enterprise/security

I trust LastPass's security as much as I trust any company's security. I'm not worried about MITM attacks, but there are many other ways that someone could get access to an account.

The biggest security issue is that they hold the keys to my entire kingdom. So if someone somehow gains access to that account, I need another layer of protection, no matter how small the chances are.

I'd recommend 1password over LastPass. LastPass has had some real facepalm security issues, and 1Password has a reputation for passing some pretty strenuous audits. We used LastPass on the tech team at HFA and... I think everyone I know has switched to 1Password or something else. I do 1Password and Yubikeys.

thanks! I used to use 1password - are you sure there haven't been similar problems? [1] I'm happy to switch but it's hard to know what to trust without being a subject matter expert here...

https://www.theregister.co.uk/2017/02/28/flaws_in_password_m...

Oh yeah it's had issues. As a more paranoid than most user I don't use the browser extension or the internal browser in the mobile app, which I catch more than a little flak for haha.

Mostly I'm making an appeal to authority to tptacek [1].

https://duckduckgo.com/?q=tptacek+1password+site%3Anews.ycom...

DashLane in the streets, 1pass in the sheets.

My 1pass vault is decentralized, and also includes a robust password generator for making stuff on the fly -- something Dashlane lacks. I'm not sure I'm using either service fully, but one of them is a work freebie and the other is from back before 1pass went to a subscription model.

... the idea isn't that either are perfect, but since password sharing and phishing are a bigger attack vector than whether my phone falls into the wrong hands, using 2FA as anti-phishing insurance is still better than not.

I've used Google Authenticator for a long time, but the lack of backups is a really serious downside. What I would really like is encrypted backups using a strong passphrase that I can write down on paper (like Authy), but from a trusted source like Google, and with no other features to widen the attack surface (no internet access, no SMS).

Without backups, having a phone die or get lost is a very frustrating experience. If you use backup codes, you have to go re-register 2FA on every account with backup codes. And of course some don't offer backup codes.

You could screenshot and print out the QR code at registration time (I've done this for a few accounts), but shared printers apparently retain history of everything they've printed, so you'd need to own a personal printer, which seems absurd.

You could write down the TOTP secret on paper instead. Ideally with multiple copies and then move them to different physical locations. That's a big hassle to do for each new account registration, which seems to happen every few months.

Encrypted backups solve this easily: you get one key, which you write down once and distribute to different locations if you want. After that there's nothing new to do for new accounts at registration time. And restoring onto a new phone after one dies is also easy.

Totally agree, I had my phone stolen a few years back. Had to buy a new one. What a surprise when I restored Google Authenticator and all my sites were gone.

However I do have an issue with 1password's feature of auto-filling those codes, seems like it's just invalidated the whole "something you have" party of MFA.

For me Authy is a happy medium

Google Authenticator is backed up on iOS if you use an encrypted local backup via iTunes (or macOS Catalina) or iMazing.

Mmm, does that mean that now your iCloud password unlocks all your 2FAs?

It isn't that bad, it still a 2nd factor, but it's worth considering it.

When you make an encrypted backup, you enter a separate passcode. So it’s not your iCloud password.

I've been using the OTP Auth[1] app on iOS as it has support for encrypted backups with a passphrase. It also offers iCloud backup but I have that disabled as I'd rather manage the backups myself. No affiliation, just a happy user.

[1]: https://apps.apple.com/us/app/otp-auth/id659877384

Google Authenticator is backed up on iOS if you use an encrypted local backup via iTunes (or macOS Catalina) or iMazing.

Use the text based secret and save a copy in an encrypted file and keep it on a usb memory stick. Put that in a safety deposit box if are paranoid enough. Either way, you lose your phone you have all your auth secrets available to re-enter.

Right, so ideally I would like to keep something in a safe deposit box (or similar), but the point is I don't want to keep going back and forth to the bank every time I sign up for a new account with 2fa. That's why I want one long-lived secret that I can put there, and have the TOTP secrets encrypted with that one.

Hi David,

I built exactly this: https://github.com/yeo/bima

I stored everything into a SQLite in `~/.bima/bima.db`

Your OTP secret is encrypted using a master password that you chooese. I use AES GCM for encryption: https://github.com/yeo/bima/blob/master/shield/encrypt.go#L1...

You then has 2 options to backup/sync among device it:

1. backup that file using dropbox, icloud, google drive 2. Enable sync to my backend. You sync encrypted data, even me cannot see it. Then other device can sync from my backend, and you enter your master password to decrypt it.

Entire thing is open source, implement using Golang Fyne UI toolkit so it run across linux/mac/window/ios/android.

If you want to help beta test it, I can send you a beta build.

I definitely want to keep 2fa secrets on a phone, not my laptop, otherwise it's not a true second factor. If you have an Android build to try, I'll check it out.

Also, part of my ideal requirements is an app built by an entity that I trust as much as Google. Open source is great, and this app is simple enough that I can skim the code once, but I'm not going to do it for every update, and I might miss something. There's still something to be said for that kind of accumulated trust. (I might not trust Google as much as I used to, but I still keep my life on gmail, so I have to trust them pretty far.)

I agree with you on the advantages of U2F/WebAuthn, but the rest of your comment seems pretty oblivious to the usability challenges of TOTP MFA. The security risks that you cite are remote and orthogonal to the security risks of not having MFA in the first place. Trying to shame users into obeying the finer details of the TOTP RFC won't work. Let's just nudge people over to U2F instead.

> - The keys not being backed up or or synchronised across devices is not a bug, but a feature. You're supposed to keep offline backup keys. Any sort of synchronization feature adds a ton of attack surface.

And it's easy enough to synchronize multiple devices to the same qrcode when setting up 2FA so that you can generate codes from a backup device if one goes missing.

If your account get hacked, then the one includes hacker's phone. The whole point of totp is gone. Hackers no longer need to stole your phone physically. Hack your account is enough.

Security is a set of compromises.

>> In particular, Authy, LastPass and 1password have a giant attack surface compared to a simple app like Google Authenticator.

Source? I've seen some vulnerabilities over time, but the "giant attack surface"?

This sort of user-hostile approach is not a net positive for security, because most people don't want to have a bunch of offline backup codes for each one of the hundreds of websites they have signed up with.

Yes, but that is because TOTP is user-hostile. The solution is to migrate to a more secure and less hostile mechanism, not to compromise on security.

Last time I checked, by default, Authy codes were susceptible to SIM-swap attacks.[0] This is a bad article.

You should perhaps consider switching off of Authenticator to an Open Source manager like AndOTP; I think that's something reasonable to propose. But I don't understand the argument that I should be very concerned a lack of biometric locks, but not concerned about invalidating the "something you have" part of 2FA.

I don't think it's horrible if someone uses an app like Authy. It's better than nothing. But this article didn't need to exist -- if you use Authenticator, just keep using it, it's fine.

[0]: https://nitter.42l.fr/DanielShumway/status/10920819670074982...

Authy only has SIM issues if you give it your phone number. Don't do that.

The linked article is recommending Authy over Authenticator because backing up codes on multiple devices is too hard. If you're going to disable remote backup on Authy, then there's almost no advantage to switching away from Authenticator in the first place. Authy also doesn't allow local export of tokens, so there's no advantage there. I guess with Authenticator you lose the ability to lock your local tokens with a 4-digit pin, but who cares? 4-digit pins are not secure.

I just checked on an old installation of Authy, and as far as I can tell there is no way to remove a phone number from the app itself, only change it. Maybe when you're installing you can skip that step. You can turn off remote backup entirely, but see above.

If you use Authy, fine. It's still better than nothing. Really, getting people to use 2FA at all is the important battle, and the fight over which 2FA app is best is probably a waste of time. But Zdnet should not have written an article recommending people switch away from Authenticator to Authy when Authy's primary selling point is actually an attack vector that its own support website recommends disabling[0].

More to the point, the setting makes me trust Authy less in other security areas, because it's an attack vector that they easily could have plugged years ago -- and it makes me think they haven't actually thought that much about security. It's just bad UX to ask users for an encryption password when a single setting will non-transparently bypass that password requirement for some tokens.

[0]: https://support.authy.com/hc/en-us/articles/360012427914-Is-...

You're right... I take back my comment. For some reason I thought that I had removed the number from Authy. I definitely have multiple devices turned off, which is definitely a confusing bit of UX.

I had a long thread with @philnash (Twillio which owns Authy) not too long ago... this is his reasoning...

https://news.ycombinator.com/item?id=22022814

While I do not agree with him about having SMS enabled at all, I can listen to his reasoning.

I also agree with you... Authy has been treated a bit like a bastard child once it went to Twillio... the updates are few and far between. The UX isn't great and hasn't improved.

Seems like a good opportunity to build something better.

You can have a mobile number based backup and restore on SAASPASS Authenticator without SIM swap issues by adding a custom password as well. Alternatively you can have it on multiple devices without a mobile number by cloning it.

Interesting. Never heard of that company before. What a horrid name. But their app looks interesting and is free for personal tier. I'll check it out. Thanks!

The only time I have ever seen Authy recommended was by sites using SMS TFA.

I wanted to use TOTP or a challenge-response key but none of the sites I use Authy for support that.

Last few times I've set up new devices, I've had to 2FA using an existing device on my account, not just the phone number. You can also disable the multi-device switch in settings which will not allow adding any new devices to your account until disabled.

Authy keys are encrypted with your passphrase before they are synced. You can't reset this password even after SIM-swap.

Authy has its own in-house format for keys that it uses alongside the open Authenticator standard. Keys stored in Authy's format don't need a passphrase to decrypt.

Authy could encrypt your entire database before syncing it, regardless of the key type, but they don't. I mention in the Twitter thread that (at least at the time) Cloudlfare's tokens fell under this category and were vulnerable to SIM-swap attacks[0].

It's possible since then Cloudlfare has switched back to using the Open standard instead. I haven't checked because I don't use Authy anymore -- I dropped Authy specifically because I personally verified 3 times in a row that my Cloudflare token did not require a passphrase to decrypt on new devices.

[0]: https://nitter.42l.fr/DanielShumway/status/10920953954785566...

Bitwarden is a pretty good solution for this! It's not the smoothest since the browser extensions don't know how to fill in your codes like they do your password but it's leaps and bounds above the UX for Google Authenticator.

Being able to access my codes from any device with a web browser is very nice.

INB4:

"But this reduces your security."

* Yes, but I'm already using a password manager with 64 char generated passwords on every site.

* If you're able to compromise my Bitwarden password you likely have enough to remove the 2FA on all of my accounts anyway.

"Why even have 2FA at that point then?"

* Because some things in my life require it.

I just paid for my second year of Bitwarden. I love it.

Also if your local machine is compromised, which is much more common than people brute-forcing passwords, somebody can get your password and a 2FA code and access any account.

Thanks for posting this. The threat modeling in this thread feels very much out of wack with my personal experience. The thing that has lead to the most compromised accounts for myself is old, short, unchanged passwords on accounts I had forgotten that probably have been leaked.

I've found the Bitwarden browser extension has an option to automatically copy the 6 digit code after the username+password autofill. Can't remember if it does it by default though. See:

Settings / Options / Disable Automatic TOTP Copy

Another shout out for bitwarden. Being open source, you can self host, and it has become a semi-standard of sorts, with alternative implementations.

As a sibling mentions, when you fill inn the user/pw of an account with 2fa enabled, the 2fa pin should be copied into the clipboard by default. (so the flow is: autofill username/password; submit, paste pin;submit).

Still think it's silly there's no simple way to get an encrypted backup of the 2fa-secrets from Google authenticator - it leaves the user and an attacker (with effective root on the phone) on uneven ground. For the user the app pretends that there is no shared secret with the server that could be compromised - the attacker simply access the sqlite db.

Since FreeOTP (iOS and Android) is open-source and free, it seems trivial to add an export/import feature that can store/load from an password-protected (argon2), encrypted (AES) file.

https://freeotp.github.io

https://github.com/freeotp/freeotp-ios

https://github.com/freeotp/freeotp-android

This isn't suitable because it doesn't allow saving it as a file:

https://github.com/freeotp/freeotp-ios/pull/129

> Is it risky "centralizing" this data? Sure, but I don't see it any more risky as using a cloud-based password manager.

Using a cloud-based password manager is a huge risk though. And if you've put both your passwords and your 2FA generators in the cloud, you now have single-factor authentication.

>> you now have single-factor authentication

In many cases that factor is now Google's security vs. the same reused password that is your hobby + the year you graduated high school. It this is what makes it convenient enough to always use, it's probably still a step up. It's at least a better, slightly more distributed factor. And even then they're distinct systems, possibly not even within the same cloud.

This.

It is a real problem that a lot of people fail to understand why this is an issue.

It's less secure, but the single factor is a stronger single factor than a password because it can't be reused. If someone mitms my login they get my password and otp code, which they ideally can't turn into something reusable (if the website requires 2FA to change security settings) and definitely can't use if they have a lag between collection and exploitation (like a keylogger that phones home every so often). This is acceptable to me, but I would prefer websites let me use a one time code as a single factor of authentication.

I stopped using Google Authenticator in 2013 when my tokens disappeared after a software update [1]. They were restored in the next update, but I didn't like not having access to the raw TOTP data.

I switched to Authy after the incident, and now use 1Password after I discovered their TOTP feature.

[1] https://news.ycombinator.com/item?id=6325760

Isn’t that putting all eggs in the same basket?

Yes and no.

Yes, it puts 1Password as the only point of failure iff 1Password security is compromised. This would require knowing my Master Password, my Secret Key, and 2FA with either my OTP from Google Authenticator or a Yubikey to open the vault on a new device, or knowing my master password on a device that I already have 1Password set up on.

On the flip side however, for anyone who _doesn't_ know I use 1Password (oops), any credential stuffing attack or password leak is not likely to get anywhere, as they're not going to be attacking my 1Password vault.

It's a compromise for me: the killer feature is not having to depend on my phone to log into websites.

I suppose it might be even more secure if I kept tokens in a separate vault.

You might be interested then in the autofilling options of SAASPASS Authenticator and Password Manager (with browser extension and iOS 12 autofill turned on).

I use Microsoft Authenticator and it has cloud backups. Maybe it's unsafe, they promise it's super safe.

https://docs.microsoft.com/el-gr/azure/active-directory/user...

I think you can turn off cloud back-ups if you want. That's what I use as well. Also -some- cloud backups don't work on it, if the tenant doesn't allow it. My Azure tenant does not, so you have to reset everything up if you get a new phone. It was a painful experience, since me and the main tenant holder both got new phones at the same time. Had to contact Microsoft directly.

Since we're apparently all sharing our 2fa methods I've really been liking the yubico authenticator. All the secrets are on the yubikey itself so if something dumb happens to my phone or computer I don't have to worry about them.

Plus, the same device does my FIDO2 / u2f / whatever it is this month for the services that support it.

U2F + Googles Advanced Protection Program = secure AF

https://landing.google.com/advancedprotection/

Yes, and OpenSSH just added FIDO/U2F support!

https://www.openssh.com/txt/release-8.2

https://www.phoronix.com/scan.php?page=news_item&px=OpenSSH-...

I've settled on Aegis.

It is open source and allows you to export secrets to an encrypted file which you can copy around.

A bit more tedious than Authy and similar cloud sync solutions but lower attack surface and less tedious to back up than Google Authenticator.

Available on F-droid. Beware of Aegis knock-offs on Google Play Store that use similar name.

I stopped using Authy because it has auto-update that you cannot disable. One day it auto-updated itself to a version that would not run on my OS. Also, it's an electron app, so it is absurdly heavyweight for the tiny bit of functionality it provides.

I ended up writing my own TOTP app. It's about 50 lines of common lisp code.

Authy Desktop

  Memory / Real / Shared

  71.3 MB 116.8 MB 96.3 MB

  > du -sh Authy\ Desktop.app/
  142M Authy Desktop.app/
  
  > du -sh Clozure\ CL.app/
  35M Clozure CL.app/

disk space is cheap, ram is expensive.

  > ps ax -o %mem,comm | grep dx86cl64
   0.4 /Users/ron/devel/ccl/v1.11/Clozure CL64.app/Contents/MacOS/dx86cl64
  
  > ps ax -o %mem,comm | grep Authy
   0.7 /Applications/Authy Desktop.app/Contents/MacOS/Authy Desktop
   0.2 /Applications/Authy Desktop.app/Contents/Frameworks/Authy Desktop Helper.app/Contents/MacOS/Authy Desktop Helper
   1.1 /Applications/Authy Desktop.app/Contents/Frameworks/Authy Desktop Helper.app/Contents/MacOS/Authy Desktop Helper

No matter how you slice it, Authy is just an outrageous resource hog.

Yes, exactly like he said. Absurdly heavyweight for the functionality it provides. The oathtool command line utility uses 1660KB generating a TOTP.

Would you mind sharing it? I considered doing this exact same thing but found the mess of standards a barrier to entry.

For those who have not seen the previous HN threads this past year on 2FA, Aegis has emerged on Android which a number of folks (myself included) have migrated to using: https://github.com/beemdevelopment/Aegis (links to G-Play/F-Droid in readme) A backup (encrypted or plain) of your seeds can be exported/imported.

This is amazing! Thank you very much, I will set it up along Google Auth in my phone and add it to my home "backup phone".

One thing that had bothered of Google Auth for a long time is the fear of losing my phone and having to go hunting down all the authentication information. And never considered Authy because using an "online service" for these kind of things just seems wrong to me.

This thread is a perfect example of why security is hard. Even if you give users the tools to improve their security (2FA apps), and even if you enforce they they use those apps, users will always find a way to create a loophole that completely negates the security enhancement you implemented.

If you’re putting all of your OTP codes in your password manager, that completely negates the entire point of two factor authentication.

And sure, maybe you think “well I’m not a high value target anyway, I don’t need to really secure my devices”, how many of you have work-related accounts signed into your devices? Even if you’re just a lowly engineer, I can guarantee you absolutely are a target of sophisticated hacker groups (ironically you may even be more of a target because these groups know that you don’t consider yourself a target and therefor are more lax with your security).

It's bad practice sure, but to say that it "completely negates the entire point of two factor authentication" is ignoring the main attack password managers are good at defending against: credential stuffing.

Example: If LinkedIn leaks my password, attackers can't use it to gain access to my Gmail because (thanks to the help of a password manager) I use different passwords for all sites. They also can't use it to gain access to LinkedIn because I have 2FA turned on. Even if my OTPs are saved in my password manager, they would need my master password for that.

And if they have someone's master password, they're probably screwed whether or not they have OTPs in their vault because they likely have credit card numbers, addresses, social security numbers, etc in there too.

I'm not sure the author on zdnet understand the security implications for "Device surfing". That is conceptually convenient, but really a terrible idea! A new token should be generated for each separate device, but not all token providers support multiple floating tokens.

It's always a battle of convinience versus security, and I get it... people think that because some services have lowered security to allow device surfing, yet without knowing the implications, that it's then just some kind of abstract non-issue taken care of by magical security things not understood. In other words it takes a big leap of faith, that was improper.

"Still using Google Authenticator? Let me recommend a replacement with a significantly larger attack surface."

I don't know what the current situation is for iOS, but on Android I've been using andOTP and it addresses pretty much all of the author's pain points (except for automated syncing between devices and the need to install it per-device, but you really should keep the number of TOTP-generating devices to a minimum; more devices = more opportunities for someone to steal that second factor of authentication).

Authy. Fantastic replacement app. makes backing everything up a snap. I can log into Authy on one device by allowing on another, etc.

Surprised is hasn't been mentioned, but KeePass has the ability to generate the TOTP codes as well. Database is stored encrypted and on your device. Use SyncThing and sync your database across multiple devices securely.

Lots of cross-platform apps to use.

Related current thread: https://news.ycombinator.com/item?id=22432828

I like Somu hardware key now. It is so small--fits inside USB slot--I keep it in an extender whem it's not in use.

And, not subject to attacks that work with passcode systems.

Use an alternative like andOTP or Authenticator Plus which allow you to backup your keys.

+1 to andOTP. It's on F-Droid and still gets semi-regular updates. It's a bit obnoxious that it requires a password, but that just means an autofill from my password manager for free at-rest encrypted storage.

I believe if you use the Android Keystore, you can use it without a password and just authenticate with a fingerprint when it starts up.

Are you not using 2FA for your password manager?

My Google Authenticator data survived me migrating to a different phone because my flow is:

1. Backup old phone using Titanium Backup.

2. Get new Android phone.

3. Root it.

4. Copy TB backup files from old phone to new.

5. Restore apps and data on new phone using Titanium Backup.

Obviously it's not a procedure a normal user is expected to do...

In Iphone I just do backup and restore in itunes. Everything is migrated. I dont see why you need to do all these.

Keys that specify they can’t be backed up are not migrated, they are not included in the backup.

I use a Chrome extension instead. Works like charm.

Just last night I was setting up “2FA” for my girls gmail account. It has so clearly become surveillance it’s disgusting. The only options are google consumer apps (or the physical key). The opportunity to link a mobile device to a desktop for advertising purposes was too great.

I have little trust that google authenticator app is any different. But as far I can see you can’t use any of these alternatives from the article.

Reply on news.ycombinator.com