New issue
Advanced search Search tips

Issue 613477 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 3
Type: Feature



Sign in to add a comment

Chrome saved passwords visibility issues

Reported by himanshu...@gmail.com, May 20 2016

Issue description

Chromium Version       : 50.0.2661.94 (Developer Build) built on Debian stretch/sid, running on Debian stretch/sid (64-bit)

Chrome saved passwords are visible to anyone having physical access to the system as they are synced from the Google account to the browser, without any authentication from chrome://settings/passwords .

What is the expected result?
There should be at least an authentication system to see saved passwords on the browser as it is on passwords.google.com.

Firefox offers option for setting up master password so that anyone with physical access to the system cannot use your saved passwords against you.
 
Components: UI>Browser>Passwords
Labels: -Type-Bug Type-Feature
Status: Untriaged (was: Unconfirmed)
This looks like a Feature Request.

Could some from Dev team please look into this feature request.

Thank you.

Comment 2 by vabr@chromium.org, May 24 2016

Labels: Hotlist-Polish OS-Chrome OS-Linux
Status: Available (was: Untriaged)
Just for context, this is a tricky area: even with requiring authentication for password viewing in chrome://settings/passwords, passwords are still easy to snoop for a local attacker via DevTools, bookmarklets, misusing sync or inspecting the local storage. Chrome is not defending against the local attacker [1]. Reauthentication on the settings page might improve privacy, but the security impact is questionable (people might misunderstand that "protection"). Note that passwords.google.com does not have this problem: the website itself never causes the passwords to be stored on the local device, so there the reauthentication is indeed a good security measure.

Having said that, in the past, the decision has been to provide reauthentication in the settings for privacy purposes. It is there for Win and Mac, and will be there for mobile once we launch viewing passwords there. So we should add it for Linux and CrOS as well.


[1] https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-
There should be some way. Some of which I could figure out is encrypting
the localstorage database which is stored in sqlite3 format.
The database is locked when chrome is using it, but not when chrome is
closed. So, encrypting it can be a way.

The implementation can be similar to the way passwords for user accounts
are stored on your computer.

Another way I would suggest is to provide some cross-platform *keyring*
tool that could save passwords. For example, *Seahorse* and *KWallet* can
be used on Linux to store passwords and those wallets are not accessible
without your password. So, there's a safety feature for Linux.

There is similar *keychain* tool for Apple systems.

Windows has it's own credential system (which anyone hardly uses).
And this ignites with an idea of a keyring system for all devices including
Android. How's that?

Those are different tools for different platforms and intergrate with other
software in different ways. If such feature is built into chrome which
makes it available cross-platform or available tools like Seahorse are
forked to be available cross-platform it would be a great feature.
That's a suggestion.

"*Chromium is open source. So being a student I would had definitely
contributed if I had a considerable level of expertise."*

Comment 4 by vabr@chromium.org, May 25 2016

Ad #3 -- this is way beyond the scope of this feature request. Chrome is not meant to replace the OS (except on Chrome OS), it is a web browser.

Once you are ready to make the code contribution, you are of course free to start a new bug and discussion with our security team, if you have a concrete plan for improving security.

Comment 5 Deleted

Thanks vabr!
Got it.
You can now close the issue. :)

Comment 7 by vabr@chromium.org, May 30 2016

Status: WontFix (was: Available)
Thanks!

Sign in to add a comment