
Disabling Google 2FA doesn't need 2FA if you're already logged in - Garbage
https://www.infoq.com/news/2020/07/google-password-2fa-woes/
======
Wowfunhappy
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.

~~~
quicklime
I’m not going to say whether this is good or bad for security, but it did save
me a few years ago when I accidentally dropped my phone and broke it.

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

~~~
Macha
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?

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

~~~
Wowfunhappy
That security key works fine in an office environment, but becomes a lot more
annoying on, for instance, a mobile device.

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

[0]:
[https://www.macrumors.com/2019/11/12/ios-13-3-fido2-security...](https://www.macrumors.com/2019/11/12/ios-13-3-fido2-security-
key-support-safari/)

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

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

------
kogir
To be fair, remote access to the user’s account on the machine is game over,
regardless.

Knowing the password and having access to a trusted (don’t ask again for 30
days checkbox) device is possession of two factors.

Google offers stricter validation in the form of advanced protection, which
isn’t so easily disabled.

[https://landing.google.com/advancedprotection/](https://landing.google.com/advancedprotection/)

~~~
ec109685
Yeah, why wouldn’t the hacker wait until the user logged into their 1Password
manager start stealing passwords that way?

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

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

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

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

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

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

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

~~~
bluesign
"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?

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

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

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

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

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

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

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

------
NewEntryHN
In order to disable 2FA, Google requires an authentication cookie (something
you possess) as well as the password (something you know). This is 2FA.

~~~
AgentK20
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)

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

~~~
yuliyp
Those situations are tricky: that type of login looks very much like a
compromised account.

~~~
Andrew_nenakhov
If a user, in clear and sober mind, disables 2FA, he accepts the risk of his
account being compromised.

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

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

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

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

~~~
dazc
2fa will authenticate from your phone number, so you only need a replacement
sim card from your telco.

~~~
Waterluvian
Like with the app? I can install the authentication app on any phone with the
same number?

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

------
gundmc
Discussed previously:

[https://news.ycombinator.com/item?id=23728390](https://news.ycombinator.com/item?id=23728390)

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

~~~
coder543
Or by using a U2F device, which is designed to prevent spoofing.

~~~
frei
U2F doesn't protect you from an untrusted machine, it protects you from
untrusted websites.

[https://security.stackexchange.com/questions/157756/mitm-
att...](https://security.stackexchange.com/questions/157756/mitm-attacks-on-
fido-uaf-and-u2f)

The security model relies on the browser validating the origin.

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

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

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

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

------
usr1106
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?

------
dathinab
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 _never_ _ever_ 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.

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

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

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

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

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

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

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

------
cpcallen
This article twice references password.google.com, but AFAICT no such site
exists. What are they actually talking about?

~~~
close04
It's Google's password manager with a typo.

[https://passwords.google.com/](https://passwords.google.com/)

------
aahhahahaaa
Same for Twitter. You can disable the account and when you re-enable it 2FA is
disabled.

------
tomc1985
If my phone gets stolen I need to be able to disable 2FA without having to
pass 2FA

------
tumetab1
So a session token can downgrade an account from 2FA to 1FA.

I'm pretty sure Google forgot to inform users about this new feature.

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

