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.
I just enrolled in advanced protection, and was then able to unenroll without 2FA re-auth....
I agree that requiring 2FA re-auth on trusted devices to disable 2FA would be a terrible default for users with only one method, but Advanced Protection should do more.
It is easier to trick the user into starting a remote session Than it is to convince them to unlock their vault.
It's somewhat like getting someone to invite you into their home VS convincing them to open their fire safe in front of you. One of those sets off alarm bells.
This is 100% false. You need to have a 2FA authenticated connection or be on a 2FA authenticated device within validity period to change 2FA settings. You can elect to have 2FA not remember the device you have logged into as well (ie, the remember this device for 30 days option) if you are particularly paranoid.
The headline should say - You can disable Google 2FA on 2FA authenticated connections without re-authenticating.
This is a fantastic balance in terms of security and usability. I switched iphones and google authenticator did not bring my 2FA's over, I got on my machine that had already authenticated and setup a new 2FA. Whew. Other systems were MUCH much harder to restore AND you could still get around 2FA but now with human involvement (social engineering risk). I've worked govt jobs with security so "tight" that everyone got the workarounds worked out - the social engineering would be as easy as I need reset for user X and they stopped even checking who anyone was the volumes were so high.
The loss in security is minimal here, and the loss is controllable, and it reduces pressure on other reset approaches (seriously, if you lock yourself out of google you will REALLY want to get back in).
That's a bit harsh, the actual disabling does not require a 2FA token so that part at least is true. And this is not the behavior I was expecting. On many other services I use disabling the 2FA requires 2FA confirmation and sometimes just visiting the security settings for the account requires the 2FA (if enabled). So maybe it's just "50% false"...
It does require 2FA, which makes the statement in the headline false.
It doesn't require 2FA reauthentication, which means you already passed 2FA.
You could say: "You don't need a password to log in to anyone's gmail account", while meaning that you just need to have access to their unlocked device while they're logged in.
Eh, it still comes down to how you interpret the sentence, which is non-obvious.
In your mind, "2FA" means "2FA authentication session", but in most people's mind, "2FA" means a "2FA code". And it is true that you don't need a new 2FA code. So depending on the interpretation you take, it's either 0% true or 100% true.
There’s a difference between logging into Google via 2FA and having subsequent interactions not require the 2nd factor, and turning off 2FA without a reconfirmation. You don’t want maximum usability in disabling your security mechanisms.
What threat model concerns you here? Anybody who'd be able to disable 2FA already has access to my logged in Google session on a trusted device. The game is over.
Right. Instead of debating the headline, this is the real question. The current behavior is that "someone on a 2FA authenticated session can disable 2FA". OK, so what?
Google is intentionally leaving this route open to lessen the impact of a lost authenticator. Probably this is a very significant cost savings for them -- although I don't know what their account recovery policy is for "lost" 2FA.
I'd say one risk factor here is that if someone is able to piggyback your session (e.g. CSRF) specifically into the 2FA Settings API, they may be able to get your 2FA disabled in a way that meaningfully exposes your account to a wider attack.
Another risk is similar to why you should require a password to be re-entered in order to change a password. The user is already in an authenticated session, and yet, it's still considered best practice to prompt for the existing password at the same time. This can't merely be as a second layer of CSRF protection, right? If your CSRF is broken, fix your CSRF.
I would assume the theory is to prevent an opportunist attacker with a small time window of access to your session (keyboard) from getting longer term access to your account.
Particularly for accounts that have long-lived sessions that don't have to use 2FA very often because of the cached session, you might not notice for quite some time that 2FA is no longer active.
As with most things in security, it's a double-edged sword.
Pragmatically, I believe the threat is that someone has managed to install some malware on your phone/computer/... you are 2FA logged in.
If so, then the bad guys can disable 2FA on your account without you having to prove the 2FA token. [Edit: but nowadays, at least you get emails and device notification that it has happened]
Traditionally, security teams have thrown up their hands and said - with malware installed, all bets are off.
I'm not sure I agree with that assessment these days, with state sponsored 0-days and trojans. I think that OPs sentiment is right, and Google and others should require 2FA reauthentication to remove 2FA, especially for their 'titanium' security tier.
BTW, it's interesting to ask what is the downside of requiring 2FA re-authentication: I believe the reason to not require 2FA is historical: When it was initially rolled out, a bunch of people tried out 2FA because it was the new coolness, got somehow lost and immediately wanted to disable it, but are not able to (lost token, have no idea what the heck they are doing etc) and get stuck. Since 2FA account recovery is very manual and expensive, Google probably doesn't want to take that hit.
This defeats the point of 2FA if you can turn it off without that second factor. In your example, if you don't have that authenticated session then you're still screwed... so you must design for the worst case scenario. The risk of 2FA is losing a device, which is why a proper design has other safety backups, such as backup codes, or leveraging a combination of other accounts that can vouch for you and humans in the loop.
that's not true. You need to think of a threat model. 2FA still successfully prevents attackers that do not yet have a session to connect to your account.
So it is still a clear net benefit.
What it does not prevent, is attackers downgrading your account from a session that already exist. At this point it is easy to argue that if an attacker has this kind of access then the only thing you can do is add 2FA to all critical actions, not just removing 2FA (that would be the least of your issue), but every critical action you can do in the app.
For example if the app is a bank, and wants to protect against these kind of attacks, then they have to prompt 2FA every time you want to want to send money (at least).
Actually the newest version does allow export. For years it was true you couldn't export. But now they allow you to export. Thankfully.
Though I tend to use U2F. With Yubikeys and other U2F keys. I use my Yubikey to store a backup of the TOTP (Authenticator type) codes. I also set a password and touch required to generate the codes.
I'm sorry but that's really being pedantic. Re-authentication is an authentication, again. You can change (remove!) a security factor with no confirmation of that particular factor for that particular action.
> You could say: "You don't need a password to log in to anyone's gmail account"
You could say it and it would be true, just not very interesting as this is exactly what everybody expects. But if you'd say you are allowed to change the password without entering the old one it would sound pretty much like what's happening here, no?
Google is not consistent with how they treat the 2 factors (password vs. second factor). At the very least they should make it clear when enabling it under what circumstances it can be disabled. No guarantee people will read but at least the more security concerned would. You can defend their decision if you want but contradicting the situation is really not "factual", it's just playing with words.
If you have a valid 2FA authenticator, you should be able to edit your 2FA Device List for any of your authenticators. But to do that, I would still expect the site to re-authenticate the user with one of their 2FA options in order to make the change.
It's not that I can't get back into the account - it's just that I can't delete an old 2FA token that I lost. Because it asks for a code from the token that I'm trying to delete...
I see, that's a bug then. For all intents and purposes, backup codes should be equivalent to a 2FA token. So you should be able to use it when removing the old 2FA.
Well... the security benefit is precisely that nobody can access your account without 2FA. Maybe you wanted to ask "what's the point in having security if usability can become so fragile?".
The point is to give users the secure option and let them decide what to go with, or at least make it clear for the users what the expected behavior is. So far it's obviously not clear. People assume you need that since you need the password to change the password, you need 2FA to change 2FA. I mean that's why you enabled it, to protect all aspects of your account.
On the other hand you should have plenty of options to protect your 2FA: save the seed (QR code), have multiple tokens, save your recovery keys, etc. Not the least of which should also be for the operator to give you a secure reset option.
It's the opposite. I actually lost a 2FA token, got back into the account, added a new one - but I can't delete the old 2FA. You shouldn't ask for 2FA authentication of the same device that I'm deleting....
It'd be nice if they accepted the 2FA code from my other devices, but then it's questionable security; I just managed to log in with 2FA, are you asking me again to confirm my identity in order to delete old device? Ok I guess... but I can already add a new device, you know. And then use it to delete all the others.... are you really giving extra security?
there is no point of having a circle of trust in that case. i do the 2FA for my son but then son loses authentication - that should mean i can get access
if you want zero grade authentication use one of the 8 one time use codes you get in authenticator instead.
While it can help you get out of a bind if you misplaced your 2FA token/app, changing any security parameters (especially when reducing security)should require entering all authentication methods enabled for the account. Imagine how changing a password requires the old password, not just the new one.
At the very least they could make it configurable, let the user decide if they want to be able to turn off 2FA without being asked for a confirmation token.
> I switched iphones and google authenticator did not bring my 2FA's over
I recommend using an encrypted local backup created with a Mac (or iMazing), as _everything_ comes over except Secure Element-based info (Apple Pay cards, Touch/Face ID enrollment).
> I switched iphones and google authenticator did not bring my 2FA's over,
I have lost 2 FA's on other services via that means as well. I think it is easy if you have cloud backup on your phone that you think that you can just wipe your old phone and sync your new phone and you will be all set. Google Authenticator doesn't work like that.
Google Authenticator made it slightly easier with the "Transfer Account" functionality, but still requires access to your old device, so it doesn't help if your already wiped it. I personally would prefer backups would transfer all configuration, but understand this would be an additional risk.
Of course you can just use Authy, although it does introduces the risk of an attacker compromising your phone number.
> You need to have a 2FA authenticated connection or be on a 2FA authenticated device within validity period to change 2FA settings. You can elect to have 2FA not remember the device you have logged into as well (ie, the remember this device for 30 days option) if you are particularly paranoid.
To change security-related settings, it's default practice to double-check even the user's password without 2fa.
> This is a fantastic balance in terms of security and usability.
Sorry, that's plain apologetic bullshit. How often do you enable and disable 2fa? This has nothing to do with usability.
Your comment illustrates a DEEP misunderstanding of dealing with users at scale.
You have millions and millions of users.
You are proposing that the threat / benefit model is such that if they lose their 2FA device (very easy via upgrades to phones, lost phones broken phones) EVEN though they have their password and and have access to a trusted device within the validity window for device trust they will be locked out, potentially forever from their account?
Do you
a) realize how common this situation is?
b) realize how angry users will be to lose access to all their google services with basically no support route to recover that?
c) what pressure there will be to allow for other recovery methods THAT ARE EVEN WEAKER?
I've gone through 2FA reset procedures over the phone with a few companies, and in EACH case it struck me how easy it would be to socially engineer or use very minimal info to get a new 2FA when they allow these methods (ie, last 4 digits of CC was one reset piece of info). So you need to allow workable 2FA update methods so that your fallback can be pretty tight if allowed at all.
Finally, consumer accounts have basically NO recovery option if you are locked out. I had a relative get locked out, nothing to be done (they had a landline that couldn't accept text messages and the system won't do voice calls). There is NO human backup - all emails, google photos, google drive etc GONE.
You started by claiming it's "100% false" and ended up saying changing your mind and agreeing it's true but for a good cause.
I agree it's not BS but apologetic it definitely is. You are justifying a decrease in security for the benefit of usability. This in itself would be a worthwhile goal if it wasn't for the facts that it goes against reasonably expected behavior and as a user I am not made clearly aware of this or given the option to control it.
Everyone is used to being asked for password reconfirmation before changing the password so it figures that they have the same expectation for the 2FA. I know I did.
> There is NO human backup - all emails, google photos, google drive etc GONE.
That's also Google's decision. You can't use one bad decision to justify another. It's likely this 2FA decision wasn't taken to help you get easier access to your account but to allow them to have 0 support knowing 2FA issues are easy to happen especially to people who won't properly save recovery keys (most people).
This is the "It's because of our amazing success that we totally fail at things" argument. If you can't do things right "at scale," that's fine, but everyone should know you suck at servicing that level of load, for example the fact that you don't require 2FA to change my 2FA settings, and there's no support path or even a support department for when my phone falls into a port-a-potty.
You can't change 2FA with just your password - you are being confused by the headline.
You need a second factor. That is either your 2FA device, a backup 2fa, backup codes, an authenticated and still valid login session etc.
If you are security paranoid you can lockout insecure 2fa methods, never validate your device and sign up for their Advanced Protection Program.
Note however, google is VERY clear -> if you lock yourself out it is game over. They do not allow humans to override the lockouts -> period. This is obviously good for security. All the folks here complaining about this supposed 2FA issue while asking for human support to allow login override / resets really have no clue about the GIANT security hole that opens.
Witness all the sim card hijacking done through phone co's (that do allow human involvement).
Google is CRYSTAL clear.
Q: Create a replacement Google Account
A: If you still can't get into your account, create a new one.
Q: Why can't I get into my old account?
A: We couldn't be sure that you're the owner. To keep accounts safe, we can't give access to them if we can't confirm who the owner is.
They've closed the big hole (human override / corruption / bribes / social engineering). And have made it so that you have only a bit of extra risk to stay in your account. Don't like that? Don't authenticate your devices as trusted.
> but everyone should know you suck at servicing that level of load
I think that mission is pretty well accomplished, right? I mean it is basically a meme at this point that Google has declined to spend the money that would be required to offer high quality interactive support for unpaid consumer accounts. Apparently people value their services more than they are concerned about the risk of needing support.
So, within that framework, the important question for both the consumer and for the service provider is what the best security trade-off is to accomplish their various goals. I think there's a pretty compelling argument made in this thread that the current stance is more optimal that requiring reauthentication for the vast majority of stakeholders.
Have to agree, though maybe not with the tone. Speaking in absolutes, the whole point of security is to make things unusable. Then for the resource owner we open up a small hole that only they can pass through, by some proof, of varying strenuousness. Wouldn't it be so much more usable if they didn't have to do that? Yes but other people would then find it "usable" as well.
I'm not defending this, but this could be seen as a way to increase usability — if you lose your 2FA token but you're still logged into a session, you can still disable 2FA and potentially re-add the token.
Obviously though, that excuse becomes an exploit the moment you change your tone of voice, so there's that.
That's what backup codes are for, or backing up your 2FA app. Enabling 2FA is an acknowledgement that you expect to be responsible for maintaining access to your second factor: It's reasonable to require you still have it when you shut that off.
That being said, Google is far from being unique in this issue.
In theory, yes, and I think most people here would store their backup codes properly. However, there are many people who don't store them properly, and don't think about it until it's too late. They lose their token, break their phone, or lose access in one of the many other ways.
Sure, you can say "tough luck", but then people will complain, reasonable or not, and Google probably doesn't want that to happen. I think this is a reasonable compromise when it comes to security and usability.
i know my life was flashing before my eyes when i logged out of my old phone and then my new phone asked for 2FA coz like a dumbo i stored the 8 codes in google drive...
If I have 15 sites in google authenticator is it such a win that 1/15th of them will allow me to reset without needing the second factor? Backing up the app or backup codes seems needed to scale to widespread 2FA use.
Regardless of what any company/product doing specifically, I do not think it is unreasonable to require a fresh token out of an authenticator if you wish to remove said authenticator from your account.
Hypothetically, what if you had 2 forms of 2nd factor to access your account? One is a passphrase you receive via SMS and another is a hardware token you possess. Should you be able to remove the hardware token based on an SMS authenticator response? Should you be able to remove both factors if you have a current session that was authorized at some prior time via one of the factors?
I think the answers boil down to just how secure the application needs to be. If you have 2FA protection, but any authorized session is valid for a year, is this actually providing any protection? I have zero problems with the idea of being required to 2FA into my brokerage app every time I want to use it. I feel like the equation can be partially reduced to:
"If your app is not so security critical that any prior-authorized session up to 30+ days can arbitrarily remove 2FA tokens, then why have 2FA in the first place?"
The amount of time a 2FA-authorized session is valid for seems to be the hangup for me. If its really short (<24 hours), then I would say don't require a reauth to remove a token. But, if a session can be valid for months, then it is much more likely that a bad person has your laptop and wants to maliciously remove your token. The longer the session can be valid for, the more a 2FA re-auth seems to be necessary to ensure a bad actor is not involved.
But, I recognize that there are so many UX considerations when talking about massive scale products that Google puts out. Supporting mandatory 2FA re-auth for token removal would probably be an extremely expensive process, as manual verification with live persons would be required to recover accounts with lost tokens.
The cookie is not something that is "possessed". This is a case of two separate things you "know", such as a username and a password. If they added a second password, it would still only be 1FA. For it to be considered a "second factor" it should either be "something you have" e.g. a physical hardware token (or to a lesser extent a phone who has a saved shared secret, although it's arguable whether that counts), or "something you are" like a biometric verification (fingerprint, retina scan, etc)
It actually drives me mad when services turn on 2FA when I absolutely don't want them to. I had a Google account with 2FA disabled, because I planned to go abroad where it would be impossible or very costly to receive SMS. And you guess what? When I tried to log in there, Google demanded that I send in code!
I was able to circumvent it only by VPNing to my office and logging in from there.
It's not just the user's choice to make. They are not risking just themselves, they're risking all the other users that could be harmed by the compromise of their account. The bitcoin scam videos posted on YouTube, the fake Facebook likes, the spam sent to random Xbox accounts, the fraudulent credit card charges done on in-app purchases in an attacker-controlled app that get charged back, the Mugged in London scams sent to their email contacts, etc.
What you're saying is basically "if I don't wear a mask during a pandemic, I accept the risks of catching the virus". No. You are opting an indefinite number of other people into transitively catching the virus despite not accepting that risk.
> if I don't wear a mask during a pandemic, I accept the risks of catching the virus
No, your metaphor is rather flawed. Better one would be "if I don't see anyone during a pandemic, I do not need to wear a mask."
If anyone hacked my email account, I would certainly be harmed, with a very low probability. However, Google made sure that I was _certainly_ harmed by it: for quite some time I could not access a vitally important information, which caused me significant stress.
Apologists such as you miss the point: I specifically foresaw the situation, and disabled 2FA to avoid it. And still, Google decided that it knows better. Well, that was before I decided that I know better and deGooglified my life. Chrome->Firefox, Google.com->DDG, you know the drill.
>This would seem security 101, but apparently in order to make it easier for users, and to avoid them having to type their 2FA token in frequently, it is sufficent to have logged in recently to a machine to satisfy to Google that you can make security level changes, if you know the password. In other words, it's 2FA, unless you're logged on, in which case it's 1FA.
The author is wrong. It is still 2 Factor. The two factors are the password (something you know) and something you have (the session token on the machine).
If your logged-in machine is compromised as was the case here, you are already in a world of hurt. Your bookmarks are visible. You could likely get the passwords by going to a bookmark site, allowing the password manager to autofill, and looking at the password fields using the browser developer tools.
There are security vs ease of use tradeoffs. Making everything harder by assuming that even a trusted machine is compromised would result in much more of a painful user experience and would lead people to abandon password managers and 2 Factor. See for example UAC and Windows Vista.
I’m pretty sure this saved my bacon big time when I lost my 2FA phone and backup codes. I found that I was logged in on a home machine and could disable it all and set it up with my new phone.
> The other aspect that came out of Amos' investigation was that passwords.google.com seems to store your passwords in an encrypted from that uses your google login password. This allows anyone who knows your password – say, because Safari auto-filled it for you – to be able to decrypt your cloud passwords.
This up to the user, he has a choice. Google gives you the ability to use a separate password, one which Google will not remember for you, to encrypt all your Chrome-Sync data. This is your sync password. You can choose to let Google manage this for you, in which case it explicitly uses your Google password and Google could read all your sync data, or you can manage it by yourself ("Sync Passphrase"). If you switch between methods, all Sync-data (Bookmarks, Passwords, AutoFill, ...) is deleted.
If the compromise of the machine could be turned into a permanent compromise) with the ability to manipulate the UI (which seems likely on mainstream Desktop OSs, you could use that to intercept the 2FA token on the next login, and use it to turn off 2FA.
The only way to prevent that would be making the token purpose bound, and displaying that purpose on the trusted 2FA device.
Most average users are the reason for this. HN is not average, lets just get that out of the way right now.
But it's not uncommon at all for someone to hear "I need to setup 2FA" so they go do so and then not understand how it works or why they're doing it. Or have some misunderstanding such that they might know what it does but not how it functions enough to properly backup their 2FA secrets or backup codes.
This then results in a massive amount of customer support. It's also really time consuming to verify the identity of your customers and there's no really good way to do that to then disable 2FA reliably knowing you're talking to the actual account owner.
This is at least a potential way for support to assist someone that messed up and disable their 2FA without having to verify their identity with some cumbersome/unreliable method.
Since I'm seeing all these comments about people who were happy that Google does this as they lost/damaged their phone which had the only copy of their 2FA codes.
I would recommend buying a couple U2F tokens which support NFC and/or Bluetooth. 1) U2F almost impossible to phish, unlike TOTP codes. 2) You can have multiple U2F keys enabled on Google, so if one fails you have others to use.
I like Yubikeys, though they are more expensive. Yubico makes a "Security Key" which is only U2F. I like the Yubikeys as can also use them to backup TOTP codes and support PGP keys. But realistically a couple U2F tokens is all you need.
This is the same issue that plagues SMS 2FA. Services constantly treat SMS as 1FA so by sim swapping someone you can get access to their account. If SMS is truly used as 2FA, and is part of MFA, it is a much more reasonable solution. These days most services should probably gather three forms of authentication and require at least two to do anything. Username/password, email, and SMS at a very minimum, with the ability for users to opt in to QR codes or FIDO devices.
It is a good thing that most devices will be shipping with platform FIDO support soon, will make some of this a lot more bearable.
Many, many sites have an option like "don't ask for 2FA on this machine for 30 days" or something like that. If someone's on your machine, of course, then you don't need 2FA.
It would probably be a good idea to ask for password and 2fa anyway if the person wants to change any account details. But if it's a machine that can be remotely accessed, it's probably not a good idea to enable "remember me" on that machine.
This reminds me of their security checkup. I logged in to my gmail today from an somewhat unusual IP address. I immediately got an email that unusual activity has been detected and a link to security checkup. There I can click whether it's me or unrecognized activity. So what would the attacker click if they managed to get into my gmail?
Also if you explicitly log out but don't clear the cookies and then log in again no 2FA is required.
Combined with the problem of 2FA not needing 2FA to be disabled logging in at a compromised computer can totally steal your account, even through 2FA is meant to prevent this.
This mean neverever login to google on a hotel computer, library or any other computer you don't trust. Google 2FA has gaps.
Other problems with 2FA include:
- To enable 2FA with authentication app you need to first enable 2FA with SMS (but SMS 2FA is known to not be secure).
- It will also implicitly enable all your android devices to be able to provide the second factor by unlocking the device and pressing ok on some google dialog.
EDIT: Or at least it was the case for me. Due to e.g. A/B testing or regional differences it might differ.
You might want to disable both. Through I can somewhat understand why they do it as if you then lose access to you 2FA app you are also locked out of google, or at least should be if there are not other "gaps" in the account recovery process. Note that recovery keys are still another thing you can enable, print and put in a save (or whatever way you want to keep them save). And tbh. auth app + offline securely stored recovery keys seem to me the best option.
Another thing you can do without 2FA on a device that is already authenticated is generate an app-specific password which is like a persistent backdoor to your account that degrades your security until you either revoke the ASP or change your main password (which automatically revokes all ASPs).
On a tangent, I set up 2FA recently for my Amazon account and deliberatelychose to use Authenticator and avoid SMS based 2FA.
However when you are asked for your code on logging in they allow you to chose to receive an SMS as an alternative and there appears to be no way to turn that off.
On the topic of Google 2FA, why does it to confirm a number on my phone when I use it to authenticate? I have to pick one of three numbers. That's only a 1/3 chance of detecting that it went to the wrong phone somehow.
Good! I walked into a lake with my phone and Google Fi couldn't send me a new one for a week. Luckily I had a valid session that I could still use to disable 2fa, otherwise I wouldn't have been able to work for a week.
As many comments have pointed out, this is only when one is already logged in. Personally, I set Firefox to clear persistence of any kind when the browser is closed so that I always will need 2FA to log in my Google account.
Seems like weird UX to re-authenticate if the user is already authenticated, but I also see the security side of things were requiring authentication for configuring authentication preferences should be required.
I noticed the same thing last week on AWS - no requirement for 2FA when disabling 2FA on root account. Seemed strange, but I guess they figure requiring 2FA once more doesn’t add enough security..
A session token is "something you have" and paired with the password being "something you know" it's still 2fa.
Whether making that conversion or allowing disabling of 2fa without requiring the user to do a full authentication with both their password and a code is debatable. But 2fa is two of something you "know", "have", or "are" which password + session token meets.
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.