5 ms·

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, w

by m00x 6y ago

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 6y ago
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.
- baby 6y ago
  Debatable. If you lose your second device but still have access to a logged account you want to be able to disable 2FA.
  - hombre_fatal 6y ago
    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.
    - mathisonturing 6y ago
      If you're talking about importing/exporting your list of 2FA codes, I think they've added it
      - fasterthanlime 6y ago
        They have! But only via QR codes (multiple, if needed). It's clearly meant to help migrate your TOTP secrets to a new phone.
        duncanawoods 6y ago
        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.
    - graton 6y ago
      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.
  - azinman2 6y ago
    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.
    - anon102010 6y ago
      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.
    - baby 6y ago
      > 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).
- UncleMeat 6y ago
  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 6y ago
    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 6y ago
      "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 6y ago
        and he is comparing the two. Why ask for password before changing a password? Why not ask for 2FA before changing your 2FA?
buran77 6y ago
> 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.
ehsankia 6y ago
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.
lordlimecat 6y ago
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.

by m00x 6y ago

azinman2 6y ago

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.

baby 6y ago
Debatable. If you lose your second device but still have access to a logged account you want to be able to disable 2FA.
- hombre_fatal 6y ago
  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.
  - mathisonturing 6y ago
    If you're talking about importing/exporting your list of 2FA codes, I think they've added it
    - fasterthanlime 6y ago
      They have! But only via QR codes (multiple, if needed). It's clearly meant to help migrate your TOTP secrets to a new phone.
      - duncanawoods 6y ago
        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.
  - graton 6y ago
    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.
- azinman2 6y ago
  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.
  - anon102010 6y ago
    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.
  - baby 6y ago
    > 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).
UncleMeat 6y ago
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 6y ago
  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 6y ago
    "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 6y ago
      and he is comparing the two. Why ask for password before changing a password? Why not ask for 2FA before changing your 2FA?

buran77 6y ago

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

ehsankia 6y ago

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.

lordlimecat 6y ago

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.