Hacker News Reader

> This is 100% false

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

There's nothing harsh about it. It's factual.

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.

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.

Debatable. If you lose your second device but still have access to a logged account you want to be able to disable 2FA.

Great counter-point, it's not as black and white as it seems.

Google's own 2FA app (Google Authenticator) doesn't even let you export your keys.

If you're talking about importing/exporting your list of 2FA codes, I think they've added it

They have! But only via QR codes (multiple, if needed). It's clearly meant to help migrate your TOTP secrets to a new phone.

Have they? I can't see it on their IOS App version 3.01. It's only had two updates in 4 years for cosmetic stuff.

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.

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.

You already have authenticated your computer as the second factor. The article headline implies you can just use a password to remove 2FA. False.

You can use your password AND that authenticated and still valid session or device to do the reset.

Google gives you options with your free account.

1) No 2FA

2) 2FA with insecure methods

3) 2FA with security keys and authenticators.

4) Advanced Protection Program

5) Paid account options with additional options / controls.

> This defeats the point of 2FA

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

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.

"Another risk is similar to why you should require a password to be re-entered in order to change a password."

you know that google asks your password when you want to change your password right?

and he is comparing the two. Why ask for password before changing a password? Why not ask for 2FA before changing your 2FA?

to be honest I am on the side that thinks asking 2FA to disable 2FA is not necessary, now I read my comment again, it sounds like I was on other side.

on both cases, password change and 2FA disable, it is asking password (but not 2FA)

So I think when you are logged in it is 1st factor, 2nd one is password. No need for 3rd one.

An attacker gaining access is one problem.

An attacker disabling and then promptly re-enabling 2FA (thus locking me out of my own account) is a different problem altogether.

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.

> It doesn't require 2FA reauthentication

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.

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.

No, it requires a token which is one factor. Usually (but not always, as in the attack detailed in the article) obtaining that token requires 2fa.

This is behavior that I have seen with no other company.

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.

Etrade does this, drives me nuts; I can't delete old 2FA devices because I no longer have them. Where's the security benefit in that???

This is slightly different (worse IMO).

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.

> Where's the security benefit in that???

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?

> ... the security benefit is precisely that nobody can access your account without 2FA.

Except they can access it with any of the multiple 2FA registrations that grandposter can't delete.

I don't think it would weaken any security posture to allow any 2FA to manipulate all of them.

To be fair that's what backup codes are for.

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.

Another story by @fasterthanlime comes with a sensational title. I should keep track of these :) https://news.ycombinator.com/item?id=23729126

Last week he also didn't understand Google Password Manager's security model and wrote an article on it. https://news.ycombinator.com/item?id=23728390

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 got on my machine that had already authenticated and setup a new 2FA.

I've had this happen to me a few times and I was so glad this is how it was done with google.

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

Also, a better TOTP manager app; I use OTP Auth.

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

To mitigate this, after you add browsers and phones to your Authy account, you go yo Settings, Devices and disable Multi-device.

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

This is not "apologetic BS"

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.

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.

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

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.

> This is not "apologetic BS"

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

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.