This behavior definitely sounds strange. dskaram@ can you help us understand what the expected behavior should be here so we can decide if this is a security issue?

This is expected since we do attempt an offline login even when pods are hidden. The setting itself is around hiding pods, not around always sending users through an online flow.

I def see the use case here, but we'd have to deal with this as a separate feature request and not as a security risk since if users have a lock screen enabled, they can always unlock their machines without 2fa, so it doesn't necessarily buy much to force 2fa on login when users can stay for weeks on lock screen (mostly the case when user:device ration is 1:1).

I'm not sure what a pod is, but let me see if I understand correctly. I power off my chromebook. I log into my Google account on my linux laptop. I go under devices and activity. I remove the Chromebook from my allowed devices. I turn the Chromebook back on. I disable network. I do an offline login. I turn wifi back on and I'm back into my account with full access. I'm never asked for a second factor. I can still bypass 2FA. That is expected behavior?

In the scenario you describe, the auth tokens should be revoked so even though you are back into your device, online services will stop working i.e. if you go to gmail or play store, these will ask you to sign in again. Does your testing show otherwise?

Yes, I still have full access to my gmail after removing the chromebook as a trusted device. As a test, I sent myself an email from another account, removed the chromebook under devices and activity in my google account, then logged into the Chromebook with wifi disabled. No 2FA. Enabled wifi, open gmail, and the new test message is there. I can open it and read it. I'm not looking at cached data.

As a side note, I just spent another 5-10 minutes solving captchas to post this. It's not a very good way to encourage participation. :/

I'm now noticing that there is a notification telling me "Account Action Required" and if I click it, it takes me through an online login. I can simply continue to ignore it and see everything in the account. So... it seems remove trusted devices is relying entirely on client validation(yuck), and that is broken.

Furthermore, it seems to assume my yubikey is a bluetooth device, which it isn't, and I'm forced to use my Google Authenticator to login instead. I cannot log in with a security key, unless the key uses bluetooth.

Really appreciate your help on this and be sure we take the feedback really seriously. I just wanted to make sure we tease out the two issues (a) local account access is still enabled and (b) access to cloud services is still enabled. The "intended behavior" is (a) still works but (b) should stop working. So if you still get an email on that device after you've removed it from being a trusted device, that's definitely a bug (I jsut managed to repro on my account).

I'll investigate a bit more internally. Thanks for reporting!

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=554349

I just checked with the team, and removing a device from the trusted list does not invalidate the auth tokens i.e. you can still use services <https://support.google.com/accounts/answer/2544838>. It just means you'd have to do 2FA when trying to sign in again.

So I think we're back at square one where this has always been the behavior of Chrome OS offline. Breaking this would mean users are locked out of their accounts when offline. We'll add this to the feature requests which we prioritize quarterly i.e. the ability to turn off offline access to devices and always force online sign-in.

So, expected behavior? Feel free to blog about it?

 Issue 718831  has been merged into this issue.

Could we teach the device about the security key so that it can verify it locally? My concern there is the lack of feature parity: we wouldn't want the device to know the Google Authenticator secrets.

Note: since this is WAI but tracked as a feature request, removing the view restriction.

Re:Comment 13

Ideally, it would be great if it would be on par or better than a Linux laptop running yubikey-luks. One can enroll several keys set up for HMAC challenge response. HMAC can still be phished, but for the purpose of unenrolling a key to temporarily lock oneself out, it is effective.

At the very least, someone who takes my Chromebook and password at gun point should be unable to get in to my online accounts. Maybe they can see local files, but they can't run password resets at my bank. Forcing online sign in prior to accessing the account would seem to provide this.

if someone is taking your device with a gun, then they can ask for your password at the same time.  2FA wouldn't help if your device is sitting at the lock screen.

if they don't have your password, then the discussion is moot -- they already can't access your content, local or otherwise.

there are scenarios that we care about and can improve w/out creating random strawmen that don't make sense.

>creating random strawmen that don't make sense

Well that certainly escalated quickly... Here's a concrete example of people with guns demanding devices and passwords:

http://www.npr.org/2017/04/11/523313829/more-travelers-are-being-asked-for-their-cellphones-and-passwords-entering-u-s

I power down my device when I am not using it. It would be nice if it were not  possible for someone who has video footage of me entering my password to log into my account without a second factor. Even if I leave that device at work. 

I don't understand why everyone on the Chrome team is so fixated on lock screens. To me, this is about my online account security. The "Show usernames and photos on login screen" setting is misleading. It requests 2FA on every login until wifi is disabled. I did not expect to get access to my account from that device with a single factor auth. Especially so after I go into my account online from a different device and "revoke access" to that device before making an attempt. Right now, that is all possible.

I'm sorry if someone was rude on another issue. That doesn't make this less of a security issue for me. Also, Re: Comment 6... thank you for disabling the captcha here on the bug reports. It's nice when people listen to feedback.

which is not the strawman you threw up.  CBP officials having guns is not the same thing as "having you at gun point".  your life is not at risk.

no one is disagreeing with making 2FA work offline if possible.

the reason there is a diff between login and lock screen is because your data is sealed at rest.  once you login, your data is unsealed and sitting in memory.  they are not equiv security guarantees.

>the reason there is a diff between login and lock screen is because your data is sealed at rest.

This has nothing to do with lock screen. This is an online Google account 2FA bypass using a Chromebook.

After the first login with 2FA on a Chromebook, Google treats that Chromebook as a second factor. Even if I log out and power off the device, someone can log into my account with nothing but my password using that device. Even if I remove that device from the trusted devices list, someone can still log into my account with nothing but my password using that device.

In short, Google treats the device where a password is entered as a second factor. ChromeOS is simply providing an easy avenue to exploit it.

you asked a question about the difference between the two, and i answered it

A couple points to hopefully help clarify things:

1. Currently, 2FA is only meaningful when authenticating towards the cloud. I.e. if you want access to an account and start from a blank slate, then accounts.google.com puts up the 2FA check. Once you through accounts.google.com authentication successfully, you'll be able to obtain auth tokens that allow you to access cloud services without having to go through 2FA again. It's common for devices (browsers on any device, mobile phones, Chrome OS) to cache these access tokens, weakening Google account security to whatever security mechanism the device implements to protect the auth token. Note that you can see your current long-term access tokens here: https://myaccount.google.com/device-activity

2. Chrome OS currently has no notion of 2FA. Authentication and user data encryption for on-device state is entirely based on passwords. Thus, it's expected and indeed WAI in the current state of things that knowing the password will allow you to access user data. If on-device-state contains auth tokens, you'll also get cloud account access. It'd certainly be useful to add 2FA support to (local) Chrome OS authentication. This would mean that we add 2FA as a cryptographic factor to ensure successful 2FA is a prerequisite for unlocking the decryption key. This is technically feasible with U2F (i.e. the U2F device can hold a key that we'd entangle with the user data encryption scheme) and certainly a valid feature request. On a related note, there is ongoing work to enable smart cards to work with Chrome OS. dskaram@ told me recently that binding the user data encryption key to the smart card is indeed a goal for that work.

3. If you're worried about 2FA bypasses to access your account in the cloud, then the right mitigation for that would be to require 2FA checks more often when you're interacting with the cloud. IIRC, there is a setting for administrators in organizations (e.g. part of G suite / Google for work) to limit the lifetime of auth tokens, forcing more frequent 2FA. I wasn't able locate a similar knob on accounts.google.com though - I'm not sure what their thinking regarding this is, but 2FA bypass concerns to cloud account data would have to be handled by them. As a stop gap, you might be able to hack something up (Chrome extension maybe?) that removes devices from https://myaccount.google.com/device-activity periodically, which would force another 2FA. Note that devices would start to behave erratically though (e.g. sync would stop working until your re-authenticate).

Since this discussion thread is already pretty unwieldy, I suggest to break out the meaningful aspects into separate feature requests, e.g. (1) supporting 2FA for local authentication in Chrome OS and (2) finer-grained settings to configure 2FA behavior on accounts.google.com.

>removes devices from https://myaccount.google.com/device-activity periodically, which would force another 2FA.

This does not work. This is the bug report for that not working. I'm not sure if you are saying "Can't reproduce" or "I don't believe you."

I just went to device activity on my Linux laptop, and clicked the [Remove] button on my Chromebook. I then powered on my logged out Chromebook, turned off wifi, logged in with a password only, then turned on wifi and have full account access to gmail, play, this issues, google docs... everything. No 2FA. 

Not a lock screen. The Chromebook was in a powered off, signed off, logged out state. Not a lock screen.

The Chromebook has nothing but a notification in the tray saying "Account Action Required" which I can happily ignore and go about doing whatever I want to do in my account.

Re comment #22: Thanks for testing the https://myaccount.google.com/device-activity token revocation suggestion. What you're seeing suggests that the access token maintained by the browser did actually get revoked (hence the notification, but I think it should read "sign in error" - "account action" is language used in Android, do you have Play store enabled by chance which may have a separate access token?), however the browser cookies were apparently not revoked. I can see two reasons for this: (1) the browser cookies weren't actually tied to the browser access token or (2) the "remove" action doesn't actually affect any cookies that have been obtained via the revoked browser token.

I've tested a bit and find evidence of both #1 and #2:

* If I sign in via the browser after revoking my browser-level access token via myacctount.google.com, then recover the device-level access token by going through online auth on the login screen, reload google properties in tabs, then sign out, then revoke the device-level access token again, the cookies maintained by the browser remain valid. This is not surprising as the content area sign-in used to obtain cookies made these cookies without any association to the device-level access token. Perhaps rogerta@ can comment on what the intended behavior is for the edge case of doing a browser sign in when we already have cookies present.

* For the case of linked tokens (this is easily achieved by triggering a logout on accounts.google.com, then signing out, then doing an online sign-in), then I see mixed results: gmail, docs, show a login screen, however g+ and appengine cookies remain valid. calendar behaved erratically (it first showed me as logged in but then eventually decided it can't access my events after an AJAX request failed?).

I'm not sure what the expected behavior is for the removal action triggered via myaccount.google.com w.r.t. to tokens - I'll follow up internally to find out.

Anyhow, that just means my proposed stop-gap doesn't work in practice (I hadn't tried, hence my "might be able" language in comment 21).

The rest of the behavior described in comment #22 (i.e. login w/o 2FA) is according to spec, in other words I *do* believe you that this is exactly what you're seeing. This might not be what you'd like to see, but the Chrome OS side is behaving as intended AFAICT.

My suggestions on follow-up action, i.e. breaking out individual feature requests for improvements per comment #21 still stands.

Correction - the first bullet is missing a step to load Google properties without the browser-level access token present. It should read:

If I sign in via the browser after revoking my browser-level access token via myacctount.google.com, *load a couple google properties in tabs, going through a web signin flow*, then recover the device-level access token by going through online auth on the login screen, reload google properties in tabs, then sign out, then revoke the device-level access token again, the cookies maintained by the browser remain valid.

FWIW, I got a reply on my internal question regarding cookie revocation behavior observed per my experiments in comment #23. The answer boils down to caches with different expiry times being used across products, resulting in web properties appearing signed out eventually after browser token revocation when the respective server-side caches expire. I haven't re-tested, but this is plausible with the observed behavior at least.

#CBC-RS/TC-watchlist 

As with a Gmail account password change, Chrome OS requires a complete shutdown and restart.

Just signing out, closing the lid or turning wifi off /on does not sync the changed data.

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

Has there been any progress on this? I was testing this today and found it definitely bypasses 2FA for my online google account.

What I did was logged out of my Chromebook then shut down. Turned my wifi router off, so Chromebook had no network connection. Logged into the Chromebook locally and was not given a 2FA challenge. Opened a browser window, obviously couldn't do anything because the wifi router was off. Turned wifi router on. Attempted to load Gmail.com, got hit with a 2FA challenge, I did not enter 2FA, I closed the browser. Re-opened the browser and could access Gmail.com, Drive, and all online services without a 2FA challenge.

So, it's definitely a way to bypass 2FA, and online Gmail account is not protected, if a nefarious actor had my password and got a hold of this Chromebook (or any really where I was a registered user.)