This may be working as intended.

Are you signed into Chrome, and do you have password sync enabled (chrome://settings/syncSetup)?

On Google's Linux distro: 
  1. Close Chrome.
  2. Use Seahorse to lock the Login keychain
  3. Start Chrome.
  4. Decline all prompts to unlock the keychain
  5. Visit chrome://settings/passwords; observe that passwords can still be shown.
  6. Visit a web form for which a previously-stored password was saved. Observe: password still autofills.

> This may be working as intended.

I does work properly on Windows (at least on Win7+) - every time you want to show plain password it asks for Windows credentials. If it's intended behavior on Linux it means that in case I forgot to lock my screen at work (as I work with the wallet unlocked), everybody can see my passwords. That's unacceptable security risk.


> Are you signed into Chrome, and do you have password sync enabled (chrome://settings/syncSetup)?

Yes and yes.


> On Google's Linux distro: 
>   1. Close Chrome.
>   2. Use Seahorse...

When the wallet is never unlocked, the passwords are not autofilled and they cannot be shown - so that part works OK. The problem is that it's possible to print plain passwords without unlocking the wallet if it was unlocked & locked in the current session.

>every time you want to show plain password it asks for Windows credentials

This feature is not really a security boundary (it can be circumvented) and is present only on Windows and Mac (see  Issue 672451 )

Regarding:

> When the wallet is never unlocked, the passwords are not autofilled 

That's not what I see with the GnomeKeyring (via Seahorse)-- even when the wallet is locked, passwords autofill. 

Is it possible that you're testing sites for which you have not yet sync'd a password?

Friendly ping. Can you please answer the question from c#5?

> > When the wallet is never unlocked, the passwords are not autofilled 
> 
> That's not what I see with the GnomeKeyring (via Seahorse)-- even when the wallet is locked, passwords autofill. 
> 
> Is it possible that you're testing sites for which you have not yet sync'd a password?

Just double-checked. On KDE's KWallet the passwords don't autofill if the wallet is locked (KWallet password dialog pops up after entering site). I'm testing sites for which the passwords are fully synced.

> This feature is not really a security boundary (it can be circumvented) and is present only on Windows and Mac

Huh, for me this is the crucial feature; I talked to couple of colleagues they share my opinion on this feature to be very important. How do you circumvent it?

Thank you for providing more feedback. Adding requester "mmoroz@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Vaclav, may I ask you to take a look or to suggest anyone else who's familiar with the passwords world?

Also CCing Eric as per question in c#8.

I'm speculatively assigning Medium severity here, as this might be an information leak. However, it's still not clear whether that's a valid issue or works as intended.

> How do you circumvent it?

An attacker with physically-local access to your PC has a number of options for accessing stolen passwords or any other data available to the browser, as outlined in the Chrome security FAQ: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-. The simplest attack is to just visit the site of interest and then unmask the autofilled password, as outlined here: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-What-about-unmasking-of-passwords-with-the-developer-tools-

> The simplest attack is to just visit the site of interest and then unmask the autofilled password

And now, due to this issue, the simplest attack is to open password settings and see. 

Installing developer tools, browsing to site for which we want to get the password, obtaining it and then uninstalling the tools adds extra steps that only increase the overall security. Now the passwords can be accessed as an office prank.

Besides, you can set KWallet to close every given time interval, Chrome should be able to respect that setting.

Thanks for the report. I do acknowledge that this is a different issue from whether reauthentication on about:settings/passwords protects anything. In particular, the reauth is not present on Linux.

The reported issue of Chrome not respecting the closed state of the KWallet is real (I attached a screen capture of it).

Code-wise, the problem is that the settings page's structure is cached even if the tab with settings is closed. And the page remembers the list of passwords from the last successful update (before closing the KWallet). So while filling no longer works for tabs open after the KWallet was closed, viewing passwords works until Chrome is shut down.

I'm afraid I have bad news, though. Chrome's design does not account for changes to KWallet availability during its runtime. Chrome's encrypting service (used for various types of browsing data other than passwords) relies on accessing an encryption key stored in KWallet. It cannot properly save and load browsing data if the key is one available and then absent again. There is a reason the KDE Wallet manager complains about not being able to close the wallet cleanly.

Based on this my current opinion is that we are not going to fix this behaviour, because using Chrome with intermittent availability of the storage backend is not supported. I am Cc-ing my colleague cfroussios@ who has good experience with the storage backends for a second opinion.

Deleted: screencast.ogv 4.2 MB

	screencast.ogv 4.2 MB View Download

Vaclav, I don't think your comment on the encryption key in #13 is correct, and therefore not an argument against addressing this issue.

The encryption key is read only once and intentionally cached. Therefore, it is perfectly safe to lock a wallet while Chrome is running. In fact, locking while Chrome is running will have no effect whatsoever on encryption.

I think the issue here is the lack of a reauth and not the caching of the settings page. Even if we clear the cache, once issue 571003 fixed, we will be back here with the same issue. Passwords will no longer be stored in Keyring/KWallet and guarded by its locks, so we will have to guard them ourselves.

How come we don't ask for reauthentication to view a password on Linux? Does Linux lack an acceptable UI to request reauth?

Thanks for the correction, Christos.

I would like to separate the reauth in settings from the password guarding the wallet. While the password guarding the wallet is a necessity to obtain the data from it, the reauth (implemented on Mac and Win) is a privacy shield but no security measure (as elawrence@ has pointed out here).

And indeed, as described in issue 571003, Chrome will take care of the stored passwords completely. This is already the case on all other platforms, including Win, Mac, Chrome OS. That means that no external applications will be available to disable access to the stored passwords. The only supported way to do that is to use OS account protection and, e.g., lock the screen or sign out when passwords should become inaccessible. I'm afraid this is one more reason to keep the current behaviour.

(To answer your question from the end of #14: I am not sure. The reauth has been a controversial decision for its potential to present a security theatre. I recently (this week) learned that the agreement from the security team was in fact, that the reauth will go away if we can ensure the user has proper OS-level protection in place. That would explain its absence on Chrome OS, and perhaps partially on Linux as well.)

For reasons stated in #13 (disabling KWallet during running Chrome not supported) and because the plan is to migrate passwords off KWallet soon (issue 571003) I don't think we should fix this. The fix would only last until issue 571003 is done, and then we could not keep this behaviour anyway. The state is not ideal, and not filling while still showing the passwords is inconsistent. To remove this inconsistency we can either hot-fix now and deprecate KWallet later, or we can spare efforts and get to deprecating KWallet sooner. I propose to do the latter.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot