Disabling Google 2FA doesn't need 2FA if you're already logged in.
The author's core issue is that once a machine has logged in, it is considered trusted for a period of time. Google should probably make this configurable for particularly security-conscious users (assuming it isn't already), but it strikes me as a perfectly reasonable default.
Seems like a reasonable default would ask for your second factor if you attempted to remove it or add another, as these are potentially account compromising events. And since these changes should very rarely happen, it's not exactly an onerous requirement for everyday users.
I suspect there is a common use case where someone’s phone gets stolen so they lose the 2nd factor and have to disable it or add a new device because they don’t have the backup codes either.
As with all things security, there are trade offs.
I actually think their existing policy is not so bad at all, but it should notify you.
So:
1. Changing recovery emails should require 2FA
2. Changing any 2FA policy should email your recovery email
It does, after all, still require a password. We're really talking about a very, very specific use case where the attacker has a lot of access to an existing session.
I myself have had a phone break and rushed to a computer with a valid session so I could easily reset. It's really a huge UX win, and probably massively reduces 2FA burden/ support burden.
Also Google requires you to re-enter your password. The fact that his browser was set up to auto enter passwords without any prompt (not the default) and the fact that his machine was open to the internet means that Google probably had enough security here.
And it does it at unpredictable and often inconvenient times.
The periodic check is undeniably good for security. But google's impl doesn't give the user any indication of when it will happen, and it doesn't allow the user to preemptively re-auth to restart the clock.
This means that I always end up having to re-auth right in the middle of sharing my screen or right when I'm trying to quickly find a thing and in a state of flow.
On good days 1pw is already unlocked and can autofill the login. On bad days I have to manually unlock 1pw and/or hunt for the pw and hope my colleagues don't see my other saved sites and then hope that I don't accidentally paste my password in a doc or something - let alone worry about destroying what was on the clipboard before google decides to do this.
Security and convenience are always at odds, but that doesn't mean you need to give a middle finger to basic UX in the name of security.
I tried it on my laptop in chrome (via the web interface) before posting that and was prompted before looking at the second password.
It's possible the interface in the chrome native settings or the passwords.google.com interface via chrome on android (which somehow uses native lock screen auth??) are slightly different.
Also IIRC you can't just log out of one account; signing out signs you out of all accounts. That makes it even less likely that I'd ever want to do that.
You can run multiple browser profiles, or use something like Firefox Containers to sidestep this pain point. I use my own profile on a hot seat shop PC, and every user has their own desktop shortcut, which directly opens the appropriate profile in the browser. I can be signed in to multiple different Google accounts simultaneously in this way. Signing out signs out for every Google account in that browser profile; adjacent browser profiles' sign-in state is not affected by signing out on first profile. Hope this helps.
Oh, it's clearly bad for security! Lots of things that are bad for security. For the best security, Google would require all users to sign in with dedicated hardware authentication tokens every time, and also present themselves for in-person interviews in Mountain View where Google employees would personally confirm each user's identity before letting them log in. That would be really good security!
It would also be really bad for usability. Just like it would be bad for usability if you lost access to your Google account forever because you broke your phone.
As an example, my employer requires 2FA on pretty much everything, so the start of my day looks like:
* Power on laptop, log in using laptop password
* Log in to LastPass, use lastpass password, verify with 2FA.
* Connect to VPN, log in using SSO (Okta) password from LastPass, verify with 2FA.
* Open github tab, log in using the Okta password again, verify again with 2FA.
* Open JIRA ticket, get sent to Okta, skips password prompt since already logged in, verify again with 2FA.
* Open email, get sent to Okta, skips password prompt, verify again with 2FA.
* Oh, my calendar tab was already open so Google didn't know I authenticated in another tab so sends me to Okta which now expects another 2FA there once I interact with it.
Also the policy is that the lastpass password, SSO password and laptop password should be different. So that's 3 passwords and 5 2FA pushes in about 5 minutes (and again after lunch as all those sessions expire during it).
My understanding is you can configure Okta to remember 2FA on a device for a while, but our security department has chosen to disable that. This is a lot of security overhead, but in this case I'm being paid for it rather than paying for it so whatever. Can you imagine getting a paying customer to agree to this level of 2FA double checking?
And the annoyance makes people want to turn it off.
Typical solution: Make the timeout much longer so you don't need to keep doing the work
Correct solution: Deploy a second factor that isn't annoying
If your second factor is a FIDO Security Key then you just touch the key. Doing this a dozen times per day feels about as much trouble as how you have to hit the spacebar to make spaces when typing, ie you aren't even aware of it.
The VPN couldn't easily do this out of the box today (as OpenSSH demonstrates, where there is a will there is a way but I wouldn't trust a typical proprietary VPN client to not open massive security holes this way) but all the web stuff you mentioned could use WebAuthn, and Okta supports that if your employer deployed it as I understand it.
I'm hoping that more apps start accepting NFC security tokens for mobile apps. Apple says they added NFC FIDO-2 authentication support in iOS 13.3[0], but I have yet to see an app that allows me to authenticate that way.
This is certainly better, but it doesn't really get us to the point the GP is describing, where authenticating "feels about as much trouble as how you have to hit the spacebar to make spaces when typing, ie you aren't even aware of it." I have to somehow get both my phone and my token out of my pocket at the same time, and hold them together, which can be awkward on a cramped subway, or when I'm holding something in my other hand.
Apple has subsequently announced and demo'd a platform authenticator for Macs and iPhones, like the one on a Pixel (the flagship Android phone).
So then you don't need the token because the platform (ie your phone) does the multi-factor authentication itself. In this case you touch a fingerprint reader. I can hold my phone in a way where my right index finger naturally is placed to do this so it feels pretty convenient.
Again, not on iPhones today but it has been demo'd and does already exist on Android.
Android has supported NFC security keys for a long time, and I believe it's automatic for websites that support U2F. I'm not sure about iOS, in the past it used to be impossible.
I use one of these: https://www.amazon.com/Feitian-ePass-NFC-FIDO-Security/dp/B0... . Plug into laptop when using laptop, hold against back of phone while using phone, and the form factor is non-annoying on my keyring with my house keys. I was shocked that YubiKey doesn't offer a single key that works for both phone and laptop.
The yubikey 5 NFC does. I think they also have a cheaper product which does FIDO2/U2F only also via usb A and NFC too. Before that, the yubikey neo did both NFC and USB A.
> For the best security, [...] That would be really good security!
Actually, that would be very bad for security, because users would work around it. (Well, it might be really, really, good for security if it got people to stop using Google, but I doubt that's what you meant.) As the saying goes:
> Security at the expense of usability comes at the expense of security.
I was being factitious, but seriously, how would you get around an in-person interview requirement? Let's assume that Google isn't doing anything stupid—you can't just stay logged in forever, and whatever process the Google employee does on their end is reasonably protected and audited.
Yeah, I lost my phone for the first time last year, and was very very glad for this default, because I was able to remove 2FA on my now lost phone from my computer that remained logged into google services, and log into google on the replacement phone, and reset 2FA to that new device.
I don't understand why these large companies don't incorporate some type of printable backup code that can be used if your 2FA device is lost/broken. I've incorporated this type of system multiple times in the past, and it works wonderfully.
My paranoia about my devices stability and its 2FA software (LG G4 bootloop victim) means that I keep two phones with 2FA verification and applications enabled - one stays safe at all times so that in case I lose or drop my new one I can use the backup.
I've lost my phone and been able to re-connect to every 2FA service I use without any need for human interaction. For google I was saved because my laptop was still logged in and I could turn google's 2fa off.
Basically everyone else has an "I lost my device" thing and a fallback to SMS codes or email links. This certainly weakens 2FA in general, but strict 2FA is unusable in practice.
Just store your 2fa totp key or qr code or backup somewhere that is either protected by 2fa (password manager, online storage) , or is available offline (file cabinet).
Some online storage services have secure areas requiring 2fa to open which would be suitable.
Most services that use standard TOTP codes have backup codes that you can print out and store in a safe, and the ones that don't you can save the QR code that enrolls the 2FA app and use it again to re-enroll a new device if needed.
Obviously the backup codes are preferred as you're not storing a master key to all future codes, but it's a lot easier to manage than a second device (at least for me).
I hardly ever use my phone for 2FA. I have a 5 line Python script using pyotp to create my codes on all my computers.
Admittedly if a skilled hacker breaks in into my computer they could recognize what the script does and misuse it. But at least no scripted attack should ever look for it. It's not on github because my seeds are hard-coded and there is not much to generalize.
Again, like with the phone, I would always need to take it out the pocket. Which is inconvenient if the pants are in the bedroom but I am not. Or I have a different pair of pants and the contents of the pockets hasn't got swapped.
Me too. Cracked, unusable phone screen. Fortunately was still logged into Google on my desktop otherwise I wouldn't be able to change 2fa before fixing the screen.
I believe APP Suffers from the exact same issue, though APP is something I recently enabled anyway.
I don't know of a way, even with full gsuite enterprise policy access, to prevent an attack where the attacker has an active session and your password.
Some things you could do, but would not be full mitigations and likely just annoy an attacker in many cases (though that's often enough):
* via GSuite, enforce 2FA
* Enforce 2FA via hardware tokens/ APP
* Context Aware Access that validates that the login is coming from a specific verified device that is provisioned via your GSuite / conforms to policy, that way the attacker can't just steal the session/password and log in from another device? Maybe?
Really, the attack described requires like 3 different things to go wrong. I agree that there should be changes made to the system to improve this, but it's a rough model to protect a user when the attacker is sitting on the box they're logged into.
I think this still has a grace period for trusted devices? Some of the FAQs at the bottom make it sound like you don't need to use the physical key every time you log in.
Which, again, is probably reasonable for 99% of cases, but might be undesirable if you're doing investigative journalism on powerful state actors or some such.
> What happens if I lose all of my security keys?
> If you still have access to a computer that is signed into your account, you can visit account.google.com and register replacement keys in place of the lost keys.
Literally no other online service (or their security engineers) have arrived at this conclusion. Changing password has always required knowledge of the password, and disabling 2fa has always required a 2fa check precisely to defeat token attacks.
No. It's not. It's possible for people to forget themselves logged in on others machines, happens to the best of us. Requiring the user to reenter their password when changing it but not requiring 2FA when removing 2FA is silly.
2FA is meant to prevent your account from being stolen even if you log in on a compromised system.
As you must assume such a system runs a key logger and will get you password this is a problem. But not a supper big one.
Except if it's a dev-account, because then a lot of things of high importance are linked to it.
I think it's a sane default setup for the causal user. But it and a fiew other defaults should be changed by telling google that this account needs to be secure or similar.
> 2FA is meant to prevent your account from being stolen even if you log in on a compromised system.
No. No 2FA system is designed to protect you from using a compromised system, as there's no such system possible. No 2FA or any system can protect your account and data from a compromised system. It can make it slightly more difficult, but can not prevent the account take-over.
Even with u2f, if the browser lies to u2f device or to you, all bets are off.
If you value your account, you should not sign into a system you don't have trust.
> Even with u2f, if the browser lies to u2f device or to you, all bets are off.
With WebAuthn / U2F if the browser lies it can result in you authenticating to a different system or under different circumstances than you expected, but nothing else, which seems pretty far from "all bets are off".
In particular a compromised browser could tell you that you're signing into Facebook, when the actual authentication performed is for GitHub, for example.
But because the User Presence detection happens in the physical authenticator it can't fake that, it does need you to press the button, tap the sensor or whatever.
And the credentials obtained this way are inherently one-use, when you take your Security Key away, bad guys can't get any further credentials from the compromised system you stopped using. As we see in this Google example that might not stop them, but that's an application security design issue not an inherent flaw in U2F / WebAuthn.
>But because the User Presence detection happens in the physical authenticator it can't fake that, it does need you to press the button, tap the sensor or whatever.
Sure, there's a user present. That doesn't stop the account being compromised. Users tap that thing all day when prompted. You prompt, they tap, easy as pie.
If you're really advanced you could build a little mechanical arm that would reach out of the computer and tap the key itself.
>And the credentials obtained this way are inherently one-use
That "one-use" could be to add a new 2FA device that's under the attacker's permanent control.
No, if you have 2FA peopel can steal you data on a compromised system but not your whole account.
With googles 2FA implementation they can steal your whole account.
If the compromised system has no way to get your second factor it can't disable/change the second factor methods and can't independently log in.
EDIT:
Sure there are probably many other ways to then trick the user into giving 2FA permission to e.g. change 2FA auth. But this is harder and not always viable in all situations.
A reasonable default in a password-only case would be to ask you for you new and old password, so of course they should ask for your 2FA if you want to remove it, unless you think 2FA is useless.
The author's core issue is that once a machine has logged in, it is considered trusted for a period of time. Google should probably make this configurable for particularly security-conscious users (assuming it isn't already), but it strikes me as a perfectly reasonable default.