vapier, could you please take a look, or help with assigning this to the right person? Thanks!

(Not sure what the right component is here)

I'm pretty sure this is working as intended. Entering credentials for the first time is considered a "sign in", and it's at sign-in that 2FA policy is enforced. Subsequent times are considered "unlock," and for these only a password is required.

yeah, i believe this is WAI.  forcibly turning off WiFi is no different from being in a place where there is no WiFi (traveling/whatever), and we don't want Chromebooks behaving as bricks in those cases.

let's loop in a few more people who have been focusing on the auth story of late though.

Yeah I don't know what else we could do here, unless we make devices useless without an internet connection. Indeed, screen unlock is not the same as sign in or syncing.

This is NOT about unlocking the screen (nothing in the report even points at that).

It is about a completely new login.

Please note the "- Logout & shutdown the machine" step.

This is NOT about unlocking the screen (nothing in the report even points at that).

It is about a completely new login.

Please note the "- Logout & shutdown the machine" step.

> Yeah I don't know what else we could do here, unless we make devices useless without an internet connection. Indeed, screen unlock is not the same as sign in or syncing.

FIDO U2F does not need any Internet connection.

Neither does TOTP.

One does require reasonably correct time and the knowledge that those are the valid tokens.

it isn't a "completely new login".  it's about a user that has already logged into the device once.  and this behavior is WAI.

if the user hasn't logged into the device at all previously, then CrOS wouldn't allow it because it would have no way of authenticating the account w/out network.

> it isn't a "completely new login". 

The user is not "logged in", when this happens.

Yes, the user was logged in once before, but that does not make the user authenticated.


Note also the third step:
>> And just in case (we are now 'online' / wireless is active):
>> - Logout (no shutdown/reboot)
>> - Login with username, password.... and indeed asks for 2FA now

Which just demonstrates the inconsistency and why the title is stating exactly what it is doing wrong: no wifi and no request for 2FA....

Please actually read what I wrote in the original report.

i understand the scenario you're describing.  don't waste time on confusing terminology.

i'm fairly certain we have not made this guarantee in the past, and we've allowed this specifically because we don't want an offline device to be a brick.  the fact that the password used matched the one that the CrOS device last saw is sufficient to authenticate.  otherwise you'd make the same argument that there's a bypass if you update your password on the server, but CrOS still allows the old one if it's offline -- we know, and that's WAI.

whether we can do better with *some* 2FA implementations is a feature request, but this isn't a security bypass in my view -- that'd require us to have made guarantees in the past to the contrary.

since Greg has been driving the auth story from the security side, i'll leave it to him to fork bugs/resolve this.

> i understand the scenario you're describing.

I don't think you do.

But I have another one in this message for your education.


>  don't waste time on confusing terminology.

What "confusing terminology"? Is FIDO U2F confusing? TOTP? "Login"?

These are pretty well defined things, some pretty good RFCs.

This is a *security* bug report, thus I really hope that you know what these things mean.



> we've allowed this specifically because we don't want an offline device to be a brick.

But it is not a "brick". FIDO U2F and TOTP can be done *OFFLINE*.

Please note again the sentence in the original report:

"The article at [2] even mentions "No connection, no problem... It even works when your device has no phone or data connectivity."

Thus clearly some part of Chromium/Google knows about this.

I heavily suggest asking people who know how TOTP and FIDO U2F work about this....


> the fact that the password used matched the one that the CrOS device last saw is sufficient to authenticate.  

It is not "sufficient" as it completely bypasses 2FA when offline while 2FA is required when one is online.


I'll make another scenario to make it clearer what the problem is here:

---

You are at an airport, you type in your password, you do your 2FA, you feel safe, as that shoulder surfer who copied your password or that camera that is recording every keystroke do not matter too much: you got 2FA and that is a hardware token you are using, no way to copy it.

5 minutes later, your chromebook is gone.

The adversary simply disables the wireless (and thus disables the 2FA requirement in the process), and voila, with username + password they got in.


That is a complete BYPASS. Whatever the "user story is".

It is also unexpected behaviour, as people who enable 2FA expect this to work this way.

Especially, as what I show in the original report: logout or reboot and login again and you get asked for username + password + 2fa.

Again: just disabling wireless removes the 2fa step.....



> otherwise you'd make the same argument that there's a bypass if you update your password on the server, but CrOS still allows the old one if it's offline -- we know, and that's WAI.

Completely different scenario. Why are you talking about this?

>  but this isn't a security bypass in my view

Please educate on how FIDO U2F and TOTP work. They are offline protocols (minus time needing to be reasonably in sync, but that is a requirement for most crypto related things)

Or heck, read your own, user facing documentation as pointed out in the original report...

> since Greg has been driving the auth story from the security side, i'll leave it to him to fork bugs/resolve this.

Who is "Greg"?

Please realize that this bug tracker thing does not expose usernames and the fun "vapier@chromium.org" aliases don't state much about people's realnames..... there are people who do not work for Google and/or Chromium using this thing to report these kind of things.

Greets,
 Jeroen

This is a duplicate of crbug.com/696378, which consider the possibility of an "online only login option."

> This is a duplicate of crbug.com/696378, which consider the possibility of an "online only login option."

This is not about "only only login", as the bug is not public:

8<-----
"You do not have permission to view the requested page. 

Reason: User is not allowed to view this issue"
------>8

can't say if the details there tell more or not.



I'll repeat again, as per the original report: FIDO U2F and TOTP work PERFECTLY FINE OFFLINE.


Thus the question: why is it disabled when the host is offline?


And yes, being able to login when offline is a good thing. Making it "online only" does not solve that problem as people will want to login when offline.

you need to work on your communication style.  being abrasive is pointless and only serves to annoy/waste time.

the duped bug is basically what i've been describing already.  it's a FR currently.

The other bug is now unrestricted.

> you need to work on your communication style.  being abrasive is pointless and only serves to annoy/waste time.

Ehm, wow here start the ad-hominem attacks. Didn't take long.

I understand it is Friday and you want to go home but closing valid issues as "dupes" is not the way to go.

I had a high regard for security of ChromeOS. But it seems I am very very wrong about this.



What is pointless is you not reading what I have written. The initial report message is very clear about the steps to reproduce this issue.




> the duped bug is basically what i've been describing already.  it's a FR currently.

The description you folks are giving is "online only login option", it is not public thus I cannot see what the details of that are.


I'll repeat again: It is not about "online only login": TOTP and FIDO U2F work perfectly fine.... offline....


Please actually read the original bug report.


(And I have no idea what you mean with "FR".... glossary needed...)

Greg has opened up the other bug, so you can read it now.  but your aggressive postings aren't helpful.  we get it, you're smart, we're dumb, let's move on.

> I understand it is Friday and you want to go home but closing valid issues as "dupes" is not the way to go.

Please keep all comments related to the facts at hand, and not about the team members involved. Thank you.

> Please keep all comments related to the facts at hand, and not about the team members involved. Thank you.

I fully agree, attacking somebody by stating:

"you need to work on your communication style.  being abrasive is pointless and only serves to annoy/waste time."

Is very productive indeed.

> Greg has opened up the other bug, so you can read it now.  but your aggressive postings aren't helpful.  we get it, you're smart, we're dumb, let's move on.

Ehmmmm, REALLY. So, you are attacking me over my "communication style", but then state THAT?

Really!? Please do take a communication course, Google is bound to offer those.






That said, reading crbug.com/696378 it has little to do with what I reported.


I'll one-line it again as from the subject:
 "Bypass U2F Token verification at ChromeOS Login by simply disabling Wireless/Connectivity"


This has further nothing to do with being "online". TOTP and FIDO U2F can be done perfectly fine OFFLINE. As per the original bug report.

Please actually read the report and the linked items... written by Google.

I'm not sure how u2f/totp could work offline - they rely on there being a shared secret between the u2f device (token) and the server that wants to authenticate, and if it's offline then what is doing the authentication?

If it's the device the token is stored on (chromebook in this case) then this breaks the trust, since the idea is that the device is not trusted - only the server and the token...

jeroen: Can you explain further exactly how offline U2F would work in the case of full re-authentication to Chrome OS?

> I'm not sure how u2f/totp could work offline - they rely on there being a shared secret between the
> u2f device (token) and the server that wants to authenticate, and if it's offline then what is doing
> the authentication?
>
> If it's the device the token is stored on (chromebook in this case) then this breaks the trust, since
> the idea is that the device is not trusted - only the server and the token...
>
> jeroen: Can you explain further exactly how offline U2F would work in the case of full re-authentication to Chrome OS?

Thanks for the great question.

ChromeOS has a stack of awesome security properties allowing secure storage of such a token, eg in the TPM in the best case (though extracting it then can be fun ;) ), but simpler in the user's home "partition" (I am not sure how that is called specifically) that gets unlocked by the user's password.

Storing the token in the user's-encrypted home/settings is thus a good enough edition The OS doesn't allow access to various portions of the filesystem anyway.
Alternatively, store the token in the certificate store, protected by the user's password (that one has from the login step).
There is likely a number of other, and likely much better places to store it.


Indeed, if something can compromise the process (eg when in developer mode / unverified-boot), then they could possibly insert code that would just ignore the 2FA check, and go along with the password as that unlocks the user home, but that IMHO is out of scope as one has then compromised security of the system already by being in unverified mode.




One negative thing of the above is that one would have to "copy" the token from the online service to the local store, which, is not ideal (and would be a bad security practice).

Thus, maybe one variant of an answer there is to have a 'local' token: at first possibility (right after successful login with username/password/2FA and thus while online likely, though can be offered offline too), explain to the user that 2FA is not enabled when offline, and offer to add 2fa (TOTP/FIDO U2F) protection by adding a 'local' token. (Thus one will have for TOTP two entries in eg Google Authenticator: GoogleAccount + Chromebook "Local").

That would thus give two scenarios:
 1) Login while offline: ask for username + password (which is cached locally) && when enabled ask for the 'local' 2fa token
 2) Login while online: ask for username + password + online-2fa && depending on security properties allow 'local' 2fa token


The major advantage here is that the user is at minimum made aware that a offline login would bypass 2fa restrictions that they assume exist for their account (and thus method of least surprise).

In the better variant they chose to setup a 'local' 2fa (be that U2F FIDO or TOTP; indeed SMS/voice etc are not really possible for this).

>  Labels: allpublic

Sidenote: not sure if it is a good idea to publish this before the problem is addressed.
(Please see the airport scenario I describe above in the comments: everybody who thinks they are safe because they have 2FA thus have a 'weak' password like "GoogleChrome" which is considered strong is easily affected by this...)