GitLab

The goal of this CL is to protect passwords saved to the Chrome browser
running on CrOS by requiring a GAIA password entry within the last
minute to show a saved password in settings and a fresh auth token [1]
to export passwords to a .csv.

The key steps for changing the password flow for CrOS were
 -Provide passwords-section with a authToken and bound to a
  password-prompt-dialog
 -On "show password" clicks, check if there is a valid there is a valid
  and <1 minute old auth token [2]
 -If not, prompt the user for their password and check again
 -If so, go back to the old flow.

The new steps in the export passwords flow are almost the same except
that the password prompt comes up on every request [3].

The less intuitive parts of the code come from trying to tinker as little
as possible with security an UX for non CrOS users. In particular, I added
and infrastructure for pausing the password flows to allow the user to
enter their password and then resume the flow when the auth token is
received [4] and incorporated an auth token check in a way that fits the
general OS specific password safety flow [5].

I also added CrOS specific browser tests in a new file and refactored the
existing password-section browser tests to share utilities with the new
file. Beyond that there were some minor changes to the existing file
that the change required due to the more involved Polymer event
dependencies for CrOS.

---

Testing:

Beyond the browser tests, I manually tested on CrOS by
 -going through a flow of entering an incorrect password, cancelling, and
  then entering the correct password for all the affected elements
 -checking that I could freely show passwords for a minute after a
  successful password entry/auth token request
 -checking that I could not export passwords or get plaintext passwords
  after the respective deadlines of 5 seconds and 1 second through the
  standard user flow or by manually entering the requests directly into
  the JS console.

I also tested on Linux (i.e. my workstation) and Mac (a corp loaner) to
ensure that the functionality was not changed.

---

[1] In practice we require it be within the last 5 seconds because it saved
some work and provided comparable security.
[2] The auth token does not need to be passed through the
passwordsPrivate API because there is a single auth token for the
machine so just checking its age ensures that the user entered their
password in the last minute and provided it to the quickUnlockPrivate
API.
[3] Since the 5 second expiration is a proxy for immediate expiration and
in practice will rarely allow for reusing a token, we can prompt the
password on each attempt for a more consistent UX.
[4] See AuthTokenRequestorBehavior and the 'request-auth-token-refresh'
event.
[5] See PasswordsPrivateDelegateImpl::OsReauthCall().


Bug: 917178
Change-Id: I8d8e988270ff627668f2022c093e558fa0409a63
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1574684
Commit-Queue: Jordy Greenblatt <jordynass@chromium.org>
Reviewed-by: Hector Carmona <hcarmona@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#661094}