I just tested this locally on M71 - after 4 mistyped passwords, they are forced through the online signin flow. Is the customer claiming that they don't get the online signin flow? Or are they saying that they get the online signin flow but Gaia is allowing them to enter 30+ incorrect passwords without locking the account?

I don't think we want to try to build password backoff on the device - kicking them through the online flow so there is admin visibility to the attack seems like the correct course.

The customer is correct that incorrect password attempts currently do not trigger back-off or lockout. Every attempt goes through the TPM / H1 though which will enforce non-circumventable delay (at least ~100ms) for each attempt.

We actually *do want* to build password backoff into Chrome OS authentication, and in fact that is what we already have done for PINs and are planning to do for passwords (on H1 devices).

Note that even if we do force people through online password flows after N failed attempts, that fundamentally helps nothing in terms of brute forcing resistance of a lost or stolen device.

So a couple of followups:

1) I really do need us to clarify their report that they were able to attempt 30 password attempts without getting locked out by Gaia, and if so, reproduce that internally as this is a significant bug. Soushi, can you please isolate a repro for that case, as I was not able to reproduce it (were they getting redirected to Gaia, and Gaia didn't lock them out? Or perhaps they were redirected to a SAML signin page and that signin page let them try endless passwords? Or maybe they rebooted after every password attempt and somehow we didn't track across reboots?)

2) We are talking about two different vectors of dictionary attacks. Chrome OS absolutely does try to prevent dictionary attacks *through the login UI*, by forcing the user through an online signin flow after 5 bad passwords, with all of the normal Gaia brute force mitigations.

Mattias is correct (as usual :) in that an attacker that can execute privileged code on the device can directly try passwords against the H1 at the rate of 10/sec or so. This requires either the ability to rewrite read-only firmware on the device to boot a custom image, or a chrome browser exploit. If the customer is concerned about this kind of sophisticated attack on the H1, then that will have to wait for the mitigation Mattias describes.

replying the comment #6:
Sorry for the confusion. I recorded a video to make everyone on the same page.
Customer and I can reproduce the issue on the latest Chrome OS (stable).

Repro video:
https://drive.google.com/file/d/1AT30--lOzMDpHs5nL_RxqMGCutxcO3vD

The problem is that Chrome shows the dialog box to ask online, but we can ignore this alert by clicking 'Back' button, and then we can continue to try to login.
I confirmed that I can log-in with the correct password, after 40-times attempts with incorrect password.

I use GAIA credential on the video (I haven't checked SAML signin behavior yet).

This is WAI in the current status quo.

The TPM adds hardware-enforced slowdown (~100ms) which mitigates brute force attacks at the login screen (see also https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data#TOC-Managing-encryption-keys for more information on that). This is good enough for reasonably strong passwords (but doesn't help with weak passwords).

We have plans to improve this on devices with H1 (e.g. PIN sign in already has proper hardware-enforced retry limiting). There are no firm timelines yet, but we hope to get this done within 2019.

Note that the above doesn't cover the lock screen, that is a separate story.

Adding Allen and Andrey FYI and relabeling to more accurately reflect the nature of the feature request.

Let me also flip this to Status=Available and Pri-2 (as long as we don't have a target milestone though Priority isn't very meaningful anyways).