[HN Gopher] Disabling Google 2FA doesn't need 2FA if you're alre...
___________________________________________________________________
Disabling Google 2FA doesn't need 2FA if you're already logged in
Author : Garbage
Score : 280 points
Date : 2020-07-10 15:50 UTC (7 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| bob1029 wrote:
| 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.
| [deleted]
| jeffbee wrote:
| 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).
| kogir wrote:
| 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/
| frei wrote:
| 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.
| siraben wrote:
| 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.
| Andrew_nenakhov wrote:
| 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 wrote:
| Those situations are tricky: that type of login looks very much
| like a compromised account.
| Andrew_nenakhov wrote:
| If a user, in clear and sober mind, disables 2FA, he accepts
| the risk of his account being compromised.
| jsnell wrote:
| 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.
| theduder99 wrote:
| I can tell Visa I will be going abroad so that they can
| proactively be aware of where I'm traveling. Perhaps google
| could add a similar feature.
| qwertox wrote:
| One of the 2FA methods offered by Google is a printable list of
| one-use codes. Like the paper TAN-lists which were popular with
| banking.
| [deleted]
| jpalomaki wrote:
| That's not the regular 2FA. It's another security check that
| kicks in when Google detects suspicious login.
|
| This can happen also with accounts that have not been ever
| configured for 2FA.
|
| I assume you never run into this if you configure for example
| the TOTP 2FA (use code generator on your phone).
| [deleted]
| miguelmota wrote:
| 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.
| cpcallen wrote:
| This article twice references password.google.com, but AFAICT no
| such site exists. What are they actually talking about?
| close04 wrote:
| It's Google's password manager with a typo.
|
| https://passwords.google.com/
| tumetab1 wrote:
| 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 wrote:
| 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.
| [deleted]
| verandaguy wrote:
| 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.
| mtgx wrote:
| Then why even bother with 2FA? Just for the "safety feels"?
|
| The point of 2FA is that someone that gets access to your
| account, such as by saying "they broke their phone and need
| access again", shouldn't be able to do it without the 2FA code.
|
| I'm not sure if it's still the case now, but it must have been
| like at least a 4-5 years period in which auth codes/tokens
| were basically useless because Google would automatically
| fallback to SMS codes. Same issue - why offer with other
| "stronger" 2FA methods, if all of them will fallback to SMS?
| ocdtrekkie wrote:
| 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.
| loktarogar wrote:
| > Enabling 2FA is an acknowledgement that you expect to be
| responsible for maintaining access to your second factor
|
| Maybe to you and me, but to everyone else it's just a
| recommended (and in many cases forced) method to gain access
| to your own account.
|
| My mum isn't making a pledge to always have her phone with
| her, she just doesn't want her email stolen
| Koenvh wrote:
| 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 wrote:
| 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...
| sceutre wrote:
| 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.
| Wowfunhappy wrote:
| > Enabling 2FA is an acknowledgement that you expect to be
| responsible for maintaining access to your second factor.
|
| On the other hand, articles all over the place increasingly
| recommend it to _everyone_.
| tengbretson wrote:
| 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.
| NewEntryHN wrote:
| 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 wrote:
| 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)
| Wowfunhappy wrote:
| 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.
| dathinab wrote:
| 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.
| drivebycomment wrote:
| > 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.
| dathinab wrote:
| 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.
| modeless wrote:
| For particularly security-conscious users Google offers this:
| https://landing.google.com/advancedprotection/
| Wowfunhappy wrote:
| 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.
| ecesena wrote:
| Also, this seems to be the case for all major sites, not just
| for Google.
| dang wrote:
| I've added that last bit to the title above. Thanks!
| pat2man wrote:
| 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.
| ryanianian wrote:
| > Google requires you to re-enter your password
|
| 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.
| andrewxdiamond wrote:
| Why cant you just log out and back in to preemptively
| trigger the login?
| ryanianian wrote:
| That screws up your default account order if you have
| multiple google accounts for work vs personal
| kelnos wrote:
| 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.
| aspenmayer wrote:
| 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.
| kccqzy wrote:
| It might be a recent change but I think you can log out
| of individual accounts now.
| EE84M3i wrote:
| >it doesn't allow the user to preemptively re-auth to
| restart the clock.
|
| AFAICT there are separate clocks for separate high-
| privileged actions, and some actions require re-
| authentication every time.
|
| As an example, accessing a saved password on
| passwords.google.com requires re-authentication for each
| item you want to access.
| occamrazor wrote:
| IIRC it has a very short reauth delay, but not zero (i.e.
| I can look at two or three passwords in a row, but not
| more)
| EE84M3i wrote:
| 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.
| quicklime wrote:
| 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.
| ehsankia wrote:
| Isn't that what backup codes are for? Does no one use backup
| codes anymore?
| usr1106 wrote:
| 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.
| graton wrote:
| You could also use a Yubikey to store up to 32 TOTP codes
| on it. One benefit is that you can set it up to require a
| touch to generate the code.
| usr1106 wrote:
| 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.
| graton wrote:
| Ah. I actually leave my Yubikeys plugged into my
| computers.
|
| I use the Yubikey Nano. I have a USB-C version in my
| laptop and a standard USB version in my desktop PC.
| cavanasm wrote:
| 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.
| SketchySeaBeast wrote:
| 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.
| Klathmon wrote:
| 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).
| jacobsenscott wrote:
| 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.
| rabuse wrote:
| 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.
| Nrbelex wrote:
| In fact, Google does: https://support.google.com/accounts
| /answer/1187538?co=GENIE....
| saagarjha wrote:
| Yeah, pretty much every 2FA I have set up has done this.
| greenshackle2 wrote:
| Every 2FA I have setup has this. Kudos to GitHub in
| particular for _strongly insisting_ that you save the
| backup codes somewhere.
| Wowfunhappy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jimmaswell wrote:
| Correct solution to me is to just turn it all off and
| accept the tradeoff to not make your employees suffer all
| day.
| Wowfunhappy wrote:
| That security key works fine in an office environment,
| but becomes a lot more annoying on, for instance, a
| mobile device.
| jxcl wrote:
| 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...
| Wowfunhappy wrote:
| 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 wrote:
| 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.
| pat2man wrote:
| 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.
| CodesInChaos wrote:
| 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 wrote:
| Or by using a U2F device, which is designed to prevent
| spoofing.
| CodesInChaos wrote:
| I don't think there is a way around "displaying that purpose
| on the trusted 2FA device." if you want to protect against a
| compromised computer.
|
| Domain binding protects you from fishing, but still relies on
| the user's computer, including the browser, being secure. So
| it doesn't help here.
| frei wrote:
| U2F doesn't protect you from an untrusted machine, it
| protects you from untrusted websites.
|
| https://security.stackexchange.com/questions/157756/mitm-
| att...
|
| The security model relies on the browser validating the
| origin.
| googlepathetic wrote:
| Google use Bluetooth to track your Android phone even when
| Bluetooth is turned off... so what do you expect from this
| company? Google only want to extract money from your pocket.
| gundmc wrote:
| Discussed previously:
|
| https://news.ycombinator.com/item?id=23728390
| selykg wrote:
| 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.
| anon102010 wrote:
| 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).
| wnevets wrote:
| > 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.
| close04 wrote:
| 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.
| RcouF1uZ4gsC wrote:
| > 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.
| guiambros wrote:
| 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.
| gchamonlive wrote:
| To mitigate this, after you add browsers and phones to your
| Authy account, you go yo Settings, Devices and disable
| Multi-device.
| koffiezet wrote:
| > 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.
| anon102010 wrote:
| 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.
| rdiddly wrote:
| 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.
| asdfasgasdgasdg wrote:
| > 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.
| anon102010 wrote:
| 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.
| el_nino wrote:
| > 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).
| rdiddly wrote:
| 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.
| [deleted]
| buran77 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Debatable. If you lose your second device but still have
| access to a logged account you want to be able to disable
| 2FA.
| azinman2 wrote:
| 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.
| baby wrote:
| > 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).
| anon102010 wrote:
| 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.
| hombre_fatal wrote:
| 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.
| graton wrote:
| 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.
| mathisonturing wrote:
| If you're talking about importing/exporting your list of
| 2FA codes, I think they've added it
| fasterthanlime wrote:
| 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 wrote:
| 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.
| UncleMeat wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| and he is comparing the two. Why ask for password before
| changing a password? Why not ask for 2FA before changing
| your 2FA?
| bluesign wrote:
| 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.
| pdpi wrote:
| 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.
| golem14 wrote:
| 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.
| buran77 wrote:
| > 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 wrote:
| 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.
| kkarakk wrote:
| 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.
| virgilp wrote:
| 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???
| ehsankia wrote:
| To be fair that's what backup codes are for.
| virgilp wrote:
| 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...
| ehsankia wrote:
| 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.
| zaroth wrote:
| 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.
| buran77 wrote:
| > 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.
| virgilp wrote:
| 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?
| jdmichal wrote:
| > ... 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.
| alpb wrote:
| 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
| usr1106 wrote:
| 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?
| graton wrote:
| 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.
| fortran77 wrote:
| 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.
| qwertox wrote:
| > 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.
| stormdennis wrote:
| 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.
| dathinab wrote:
| 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.
| RcouF1uZ4gsC wrote:
| >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.
___________________________________________________________________
(page generated 2020-07-10 23:00 UTC)