Issue 917178: Prevent access to 'Show password' on Chromebooks

This is a consumer feature too - ideally we'd ask the user to enter their password before allowing viewing passwords on chrome os.

On Windows, MacOS, Android and iOS we ask the user to enter their OS credentials before revealing the password. On ChromeOS there is no API to do that (AFAIK). This did not make it to the password manager team's priority list because of the effort to introduce such a reauthentication mechanism.

The feature request seems to be to have a policy that disables the reveal button in chrome://settings/passwords. For this, the enterprise team would be the most skilled people because they know how to introduce policies and make them affect things in chrome://settings. --> Re-adding Component Enterprise.

Unfortunately, either way there are easy workarounds to see passwords: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-What-about-unmasking-of-passwords-with-the-developer-tools-

Also relevant: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

rarel: are you asking for an enterprise policy to completely prevent viewing passwords? Or are you asking for us to match behavior on other platforms where a user has to authenticate themselves before viewing passwords?

Hello Team,

@atwilson: the customer want to keep it private, I believe it will be better if we can align this to the authentication process on Windows and other platforms.

+Mattias on his feedback here

Thanks for clarifying - this is a general password-manager FR then (not asking for enterprise-specific functionality like a policy to block "reveal").

Lock screen is able to do a password check, so it should be possible to do a password check within the password manager. My team can help the password manager team in figuring out a reauth-mechanism on cros.

If you can tell us how to trigger the cros reauth, this should be pretty simple. For Windows and MacOS we have a call here:

https://cs.chromium.org/chromium/src/chrome/browser/extensions/api/passwords_private/passwords_private_delegate_impl.cc?l=187-198&rcl=6e5e24ecbebf5ed2c72a6946dc742b4b80d5fc6f

Asked my team, and +antrim had a few pointers:

"Lockscreen code does re-auth here: https://cs.chromium.org/chromium/src/chromeos/login/auth/extended_authenticator.h?rcl=5d061a2a324c950c11d3ddce94ab90ab233c1ebf&l=68
called from https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/lock/screen_locker.cc?rcl=5d061a2a324c950c11d3ddce94ab90ab233c1ebf&l=412"

Note, that screen locker can be disabled via user policy (https://cs.chromium.org/chromium/src/components/policy/resources/policy_templates.json?rcl=2b32f46e421683240c8cede7069940cc909c2145&l=10607), in that case attempt to lock screen would actually end user session. There are some cases (guest sessions, public sessions) that result in sign out instead of lock screen, but I am not sure that password manager is enabled for those types of session.

I think password manager should check for that cases and disable/hide reveal button.

My $0.02: There's probably a better way to do re-auth than going through the lock screen (which is a pretty big hammer). We already do re-auth for changing lock screen settings. You can see this in action on chrome://settings/lockScreen and here's a screenshot for convenience: https://screenshot.googleplex.com/UMw2MJ83ck5

This seems to be bundled up nicely in a component that already works in chrome://settings see here: https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/controls/password_prompt_dialog.html?dr=C&g=0

Thanks for the input. In principle it is a great idea. I have three concerns, though:

1) This not accessible for native UI paths that live outside of chrome://settings (the password bubble of the omnibar also has a reveal button).

2) The code paths would diverge quite a lot and reauth would happen in different layers on the different OS / contexts.

3) This increases the coding effort to a degree that I would not do it on the side anymore and it probably would not meet my priority threshold to get done by me (I'd need to familiarize myself more with Polymer first).


@atwilson, mnissler, privard:
Given the choice of a) me implementing this quick and simple, b) not getting this implemented, c) finding somebody on the enterprise team to build it, what would be your preference?


Here is what we discussed in a feature sync and would propose:

1) I build a reauth using screenlock that fires only if the user has a usable screenlock. In guestmode / public session, we assume that you cannot save passwords anyway (but would like to ask privard or somebody who knows how to set up a public session) to confirm that. If the admin configures a policy to disable screenlock, we would just show the password. This is in line with our desktop behavior (if no OS password is configured, we just reveal the password saved in the password manager).

2) We would ask the enterprise team to build a policy that disables the "reveal" password button. We could probably do that as well but given that you have experience in building policy support, it would be more economic if you took care of this.

@15: Isn't the native route to use the code cited in comment 12?  If there are concerns on secondary UI like omnibox bubbles, that would likely be the team I'm on or dfried's team to tackle; let us know if there's some feature request there.

From a UX/consistency perspective, it'd be preferable to have CrOS behavior match other OSes (which is also what comment 8 wants) rather than add a policy to remove useful functionality because we can't find someone to implement on CrOS what the other platforms already have.  Can we get implementation help from the CrOS UI team?

+kuscher, omrilio from UI

Please see thread from Alberto and security folks

Unfortunately, I'm not on that thread - can someone CC me, or move the discussion here to the bug?

In any case, the ask here is to have an auth step to reveal passwords, *not* to have an enterprise policy to remove "reveal" entirely - this is not an enterprise feature and there's no ask from Enterprise customers for a policy to control this (they can already disable sync/password manager on the device, which is sufficient for them). I'm removing the Enterprise component *again* and we'll see if it sticks this time :)

Also, to be clear, I wasn't suggesting that you activate the lock screen - that's a terrible UX. I was just pointing you at the code so you could see how auth was done. Mattias' suggestion of doing what we do for changing lockscreen settings seems pretty solid.

Anyhow, maybe this is all mooted by the Alberto thread?

Drew, I've added you to that mystic mail thread - there isn't much context there, other than the general agreement that we shouldn't just reveal passwords at the click of a button.

My take on the last couple comments:

* This FR is specifically not meant as an enterprise feature, but targeted mostly at consumer users. The FR for an enterprise policy to disable reveal seems a legit FR if organizations want that, but let's discuss that elsewhere.

* Understood re code divergence / effort concerns from comment 15. If we did the lock screen re-auth approach, we'd also end up with a stark inconsistency though (as mentioned, we already have inline re-auth in chrome://settings so our re-auth would become inconsistent). Given that, I think we need to take a step back here and work with the UX team to figure out how re-auth UI should look.

* My understanding is that Windows and Mac re-auth UI is actually not the OS lock screen, but a password prompt. So using the lock screen wouldn't achieve any cross-platform consistency (at least not to the user).

Let me add zalcorn@ as yet another PM who might have guidance. I'll start a mail thread though to try and resolve the re-auth question, I have a feeling this bug isn't the best forum to work out an answer.

BTW, I took at look at the CL and I understand why Dominic wants to go down the lock screen path - it's super simple :) So if we can't resource a better solution, I'd rather have the lock-screen implementation than no solution.