Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Downsides of Google Authenticator

zdnet.com

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Downsides of Google Authenticator

#81

Post by renton_tacos »

lima wrote: post #49
renton_tacos wrote: post #33

Earlier quoted context omitted.

>- 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, b…

> 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…

>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.

Re: Downsides of Google Authenticator

#82

Post by notlukesky »

latchkey wrote: post #72
danShumway wrote: post #34

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…

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

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.

Re: Downsides of Google Authenticator

#83

Post by dillondoyle »

J5892 wrote: post #77
ender341341 wrote: post #75

Earlier quoted context omitted.

> 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…

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

Re: Downsides of Google Authenticator

#84

Post by notlukesky »

ValentineC wrote: post #14

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

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

Re: Downsides of Google Authenticator

#85

Post by notlukesky »

ls612 wrote: post #8
lima wrote: post #4

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 compar…

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.

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.

Re: Downsides of Google Authenticator

#86

Post by brnt »

lukeschlather wrote: post #45
orev wrote: post #36

Earlier quoted context omitted.

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.

Re: Downsides of Google Authenticator

#87

Post by CraneWorm »

renton_tacos wrote: post #33
lima wrote: post #4

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 compar…

>- 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, b…

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

Re: Downsides of Google Authenticator

#88

Post by renton_tacos »

CraneWorm wrote: post #87
renton_tacos wrote: post #33

Earlier quoted context omitted.

>- 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, b…

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.

Re: Downsides of Google Authenticator

#89

Post by dnr »

lima wrote: post #4

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 compar…

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.

Re: Downsides of Google Authenticator

#90

Post by davchana »

orev wrote: post #36
ocdtrekkie wrote: post #10

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN