New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature

Sign in to add a comment

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

Reported by, Dec 20 Project Member

Issue description

Prevent access to 'Show password' on Chrome OS.

Use case:
In Chrome saved password manager, once you save a password to a website login or anything, the password is visible. I'm requesting that there is no way you should be able to click on that eye tab and see the saved password.

It's a very insecure feature in chrome that needs to be addressed. Passwords should not be visible to anyone that goes into settings and can look up any saved password.

Existing workarounds:
Not saving any passwords, which is very inconvenient, or maybe a third party passwords manager

Comment 1 by, Dec 20

Labels: OS-Chrome

Comment 2 by, Dec 21

Owner: ----
Summary: Prevent access to 'Show password' on Chromebooks (was: Enterprise support feature request)

Comment 3 by, Jan 11

Labels: Impacts-Enterprise

Comment 4 by, Jan 11

Components: -Enterprise UI>Browser>Passwords
Labels: -Impacts-Enterprise
This is a consumer feature too - ideally we'd ask the user to enter their password before allowing viewing passwords on chrome os.

Comment 5 by, Jan 11

Components: Enterprise
Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Untriaged)
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:

Also relevant:

Comment 6 by, Jan 11


Comment 7 by, Jan 11

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?

Comment 8 by, Jan 11

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.

Comment 9 by, Jan 13

+Mattias on his feedback here

Comment 10 by, Jan 14

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.

Comment 11 by, Jan 14

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:

Comment 13 by, Jan 14

Note, that screen locker can be disabled via user policy (, 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.

Comment 14 by, Jan 16

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:

This seems to be bundled up nicely in a component that already works in chrome://settings see here:

Comment 15 by, Jan 16

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.

Comment 16 by, Jan 17

Labels: Impacts-Enterprise

Comment 17 by, Jan 17

Owner: ----

Comment 18 by, Jan 17

@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?

Comment 19 by, Jan 18

+kuscher, omrilio from UI

Comment 20 by, Jan 18

Please see thread from Alberto and security folks

Comment 21 by, Jan 20

Components: -Enterprise
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?

Comment 22 by, Jan 21

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.

Comment 23 by, Jan 21

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.

Comment 24 by, Jan 22

Labels: -Impacts-Enterprise Enterprise-Triaged Hotlist-Enterprise

Sign in to add a comment