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 96 users
Status: Fixed
Owner:
Last visit 29 days ago
Closed: Jan 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Linux should encrypt passwords on disk by default
Project Member Reported by vandebo@chromium.org, Oct 21 2009 Back to list
Windows and Mac (?) use system infrastructure to encrypt stored passwords 
before they hit the disk.  Linux should do the same.

One option is to integrate with desktop environment password managers:
http://code.google.com/p/chromium/issues/detail?id=8205 
http://code.google.com/p/chromium/issues/detail?id=12351
Another is a master password: 
http://code.google.com/p/chromium/issues/detail?id=53

 
Comment 1 by jon@chromium.org, Oct 21 2009
Labels: -Pri-2 -Area-Misc Pri-1 Area-BrowserBackend Mstone-4 ReleaseBlock-Beta
Labels: -ReleaseBlock-Beta
Passwords should at least be obscured.
Status: Available
Labels: -Mstone-4 Mstone-5
The system infrastructure to support this is in transition right now, so effort here 
may just need to be repeated. This should definitely block a Linux release, but 
shouldn't block a Beta. Unless someone has strong feelings otherwise, pushing this to 
Mstone-5.
Comment 5 by evan@chromium.org, Nov 22 2009
Labels: -Type-Bug Type-Feature
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34193 

------------------------------------------------------------------------
r34193 | evan@chromium.org | 2009-12-09 13:43:02 -0800 (Wed, 09 Dec 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/encryptor_linux.cc?r1=34193&r2=34192
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/webdata/web_database.cc?r1=34193&r2=34192

linux: remove a NOTIMPL since we have a bug on it

Also, update some comments to use the new bug number.

BUG= 8205 , 25404 

Review URL: http://codereview.chromium.org/483003
------------------------------------------------------------------------

Comment 7 by oritm@chromium.org, Dec 17 2009
Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Comment 8 by evan@chromium.org, Jan 9 2010
Since we're unlikely to get past hardy, we're unlikely to be able to fix this by using 
gnome-password or whatever.
Labels: -Pri-1 Pri-2
Comment 10 by evan@chromium.org, Mar 15 2010
Status: Assigned
Preemptively assigning to mdm, I htink we can use the KDE pw manager via dbus
Comment 11 by mdm@chromium.org, Mar 26 2010
Status: Available
It would seem that I will be working on AdSense and not Chrome, so I won't be able to do this right away. 
Perhaps if it can wait I can throw some 20% time at it later, but definitely not for Mstone-5.

There is disabled code to use both GNOME keyring and KWallet, although it needs to be brushed off to compile 
again. (In particular some new virtual methods have been added that need to be implemented.) Perhaps rather 
than using these directly, and introducing a dependency, it wouldn't be too hard to tweak this code to load 
them dynamically? Then we can use whatever's available and fall back to the unencrypted version only if 
neither is installed.

As an aside I personally agree with the reasoning that merely obscuring passwords is not a good idea since it 
provides a false sense of the level of security actually present.
Labels: -Mstone-5 Mstone-6
If anyone feels strongly enough about changing this behavior for mstone:5, who doesn't have any P1 bugs, 
please feel free to take a swing.
Mac as well. I just removed   NOTIMPLEMENTED(); in encryptor_mac.mm, so it does the
same thing as encryptor_linux.cc: just copies the data. But the person implementing
it should remember about mac as well.

The mac doesn't store passwords in the database. Why did you remove the NOTIMPLEMENTED? If anyone ever 
starts using encryptor_mac we need to know, because that would be bad.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44984 

------------------------------------------------------------------------
r44984 | georgey@chromium.org | 2010-04-19 16:28:32 -0700 (Mon, 19 Apr 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/encryptor_mac.mm?r1=44984&r2=44983

Removed NOTIMPLEMENTED() from Encryptor::EncryptString() and Encryptor::DecryptString() in
chrome/browser/password_manager/encryptor_mac.mm, so it does exactly the same thing as on Linux: copies unencrypted text.
BUG= 25404 
TEST=Filling out Autofill for CC on Mac should not assert.
Review URL: http://codereview.chromium.org/1613024
------------------------------------------------------------------------

In the comments for Encryptor it says that it is needs to be implemented for Linux
and Mac (see comment from thestig @ line 28 in web_database.cc). As it I added use of
general Encryptor to encode CC numbers stored locally, I removed NOTIMPLEMENTED(), so
it does not assert on Mac. We *do* need to implement it eventually, as not only
passwords need to be encrypted.
IMO, we shouldn't be designing around Encryptor as a cross-platform concept at all. On the Mac, the solution for 
sensitive data should be to use the Keychain, rather than re-inventing something for secure local storage.
Is web_database used on Mac? Because if it is the password there is saved through the
Encryptor and not through the Keychain.
Password storage via WebDatabase is deprecated, and shortly no platform will use it. PasswordStore is the 
abstraction for password management, and does not delegate to WDS on the Mac. I wrote the entire 
PasswordStore implementation for the Mac, and I guarantee it doesn't use Encryptor.

The fundamental problem with Encryptor is that it "abstracts" a Windows API only in that it abstracts the 
platform call. It still assumes that secure local storage on all platforms will have basically the structure that it 
has on Windows. That's not the case.

I strongly feel that at least on the Mac (maybe on Linux; I don't know what the right platform solution is there), 
Encryptor shouldn't even be defined. If we need non-password secure local storage, we should figure out the 
right abstraction that actually works for all platforms, rather than encouraging new clients of a Windows-ism.
I filed  bug 42038  to continue this discussion, so as not to totally hijack this Linux bug.
Continuing discussion from  bug #8205 : there has been near zero progress in the design 
of a unified dbus API for keyrings. While I agree that such an API would be the right 
way to go, I reckon that we need a solution *right now* for not storing passwords in 
clear text in Linux. It does not make sense to be indefinetely stalled by a new API 
that nobody is actively working on.

If the only issue with the existing GNOME keyring code (aside some little bitrot) is 
that of dependency, rewriting it to use dlopen() should solve it.
How does this issue differ from  issue 12351 , where we want to turn on the integration 
with gnome-keyring and kwallet?

Is this about doing encrypted storage ourselves when neither of those is available?  If 
not, it seems like this should just close in favor of the other bug.
Blockedon: 12351
Labels: ReleaseBlock-Stable
This bug is about doing *something* on Linux.  At the time this bug was filled 12351 
was closed as WontFix and had a different summary.

It looks like kwallet and gnome-keyring integration are possible now.  A remaining 
question for this bug: is the market of linux users without either big enough for us 
to provide our own fallback?  I suspect Chrome OS doesn't plan to use either kwallet 
or gnome-keyring, so what ever solution they have in mind is probably the resolution 
to this question.
Comment 24 by hbridge@google.com, May 26 2010
I'm not sure, but I think they're planning to use hardware (TPM chips etc), so I wouldn't count on the Chrome OS 
solution being generalizable for LInux.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48983 

------------------------------------------------------------------------
r48983 | mdm@chromium.org | 2010-06-04 15:21:13 -0700 (Fri, 04 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store.h?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.cc?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.h?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_kwallet.cc?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_kwallet.h?r1=48983&r2=48982

Linux: bring GNOME Keyring and KWallet integration back into a compilable state. Still disabled, however.
BUG= 12351 , 25404 
TEST=both now seem to work correctly when enabled (but this CL does not enable them)

Review URL: http://codereview.chromium.org/2407001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48996 

------------------------------------------------------------------------
r48996 | mdm@chromium.org | 2010-06-04 19:50:51 -0700 (Fri, 04 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.cc?r1=48996&r2=48995

Linux: make GNOME keyring password store able to use libgnome-keyring via dlopen. The GNOME keyring password store is still disabled.
BUG= 25404 
TEST=gnome keyring password store can be loaded with dlopen

Review URL: http://codereview.chromium.org/2696002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49110 

------------------------------------------------------------------------
r49110 | mdm@chromium.org | 2010-06-07 15:34:40 -0700 (Mon, 07 Jun 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/install-build-deps.sh?r1=49110&r2=49109

Linux: add gnome-keyring packages to build dependencies. It will not be a runtime dependency: it will be dlopen()ed to avoid that.
BUG= 25404 
TEST=none
Review URL: http://codereview.chromium.org/2700002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49135 

------------------------------------------------------------------------
r49135 | mdm@chromium.org | 2010-06-07 18:25:58 -0700 (Mon, 07 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=49135&r2=49134
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/linux/system.gyp?r1=49135&r2=49134
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=49135&r2=49134

Linux: enable compiling GNOME Keyring and KWallet integration. It's still unused.
BUG= 12351 , 25404 
TEST=GNOME Keyring and KWallet get compiled, but add no new library dependencies

Review URL: http://codereview.chromium.org/2718001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49370 

------------------------------------------------------------------------
r49370 | mdm@chromium.org | 2010-06-09 22:45:01 -0700 (Wed, 09 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=49370&r2=49369
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/linux/system.gyp?r1=49370&r2=49369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=49370&r2=49369

Reland r49135: Linux: enable compiling GNOME Keyring and KWallet integration. It's still unused.
BUG= 12351 , 25404 
TEST=GNOME Keyring and KWallet get compiled, but add no new library dependencies

Review URL: http://codereview.chromium.org/2774002
------------------------------------------------------------------------

Labels: -ReleaseBlock-Stable
Status: Assigned
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=50034 

------------------------------------------------------------------------
r50034 | mdm@chromium.org | 2010-06-16 14:33:16 -0700 (Wed, 16 Jun 2010) | 4 lines
Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_kwallet_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_kwallet_x.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_default.cc?r1=50034&r2=50033
   D /trunk/src/chrome/browser/password_manager/password_store_gnome.cc
   D /trunk/src/chrome/browser/password_manager/password_store_gnome.h
   D /trunk/src/chrome/browser/password_manager/password_store_kwallet.cc
   D /trunk/src/chrome/browser/password_manager/password_store_kwallet.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=50034&r2=50033
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=50034&r2=50033

Linux: refactor GNOME Keyring and KWallet integration to allow migration from the default store, and add unit tests. Still disabled.
BUG= 12351 ,  25404 
TEST=unit tests work
Review URL: http://codereview.chromium.org/2806002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=50475 

------------------------------------------------------------------------
r50475 | mdm@chromium.org | 2010-06-22 10:22:08 -0700 (Tue, 22 Jun 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profile.cc?r1=50475&r2=50474
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=50475&r2=50474
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=50475&r2=50474

Linux: allow using GNOME Keyring and KWallet for password storage via a command line flag, disabled by default.
BUG= 12351 ,  25404 ,  45896 
TEST=still uses default password store unless --password-store is given with a value of detect, gnome, or kwallet
Review URL: http://codereview.chromium.org/2730008
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=52729 

------------------------------------------------------------------------
r52729 | mdm@chromium.org | 2010-07-16 13:30:42 -0700 (Fri, 16 Jul 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.cc?r1=52729&r2=52728
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.h?r1=52729&r2=52728

Linux: access GNOME Keyring on the GLib main thread, rather than the DB thread.
I was unable to reproduce the crash, but it's happening to a lot of people and the web suggests that moving access to GNOME Keyring to the GLib main thread should fix the problem.
BUG= 48343 ,  25404 
TEST=hopefully it won't crash for some people any more
Review URL: http://codereview.chromium.org/2953006
------------------------------------------------------------------------

Comment 36 by mdm@chromium.org, Jul 16 2010
Blockedon: -12351
Labels: -Mstone-6 Mstone-7
Summary: Linux should encrypt passwords on disk by default (was: NULL)
Hopefully this should now be supported, just not the default. Updating the bug title and pushing default support to M7.
FWIW, I've been using it since you implemented the migration of the passwords to the store, and it works wonderfully for me.

Thanks!
Comment 38 by mdm@chromium.org, Aug 25 2010
Labels: -Mstone-7 Mstone-8
Let's give this a bit longer to bake, and turn it on by default after we branch for M7.
So basically this will not be on by default in Chrome 6 but only in Chrome 7?
 Bug 53  seems to be a dupe, or at least its concerns are addressed by this fix.
No, master password requests are about the UI, not the on-disk storage.
Comment 42 by mdm@chromium.org, Oct 11 2010
Labels: -Mstone-8 Mstone-9
I was just about to commit http://codereview.chromium.org/3326010/show to finish this a while back, but I discovered an important bug that should really be fixed first. So, pushing this back just a bit more.
Labels: -Mstone-9 Mstone-10
Moving P2s with an owner to Mstone 10, bring back to M9 if you think it's important and you don't have higher priority work.
Comment 44 by kerz@chromium.org, Dec 9 2010
Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
I don't understand. The resolution of this bug is delayed and delayed again. This is the main issue that prevents me and a lot of other people to use Chrome on Linux on a daily basis.

Google developers working on a Linux machine, how do you store your passwords in Chrome? Do you let them in clear text in the SQLite database? Do you encrypt your home directory? Do you use something like LastPass?

I am curious to know the recommended way to use Chrome under Linux regarding password storage.

Your advice is welcome.
Comment 46 by mdm@chromium.org, Dec 14 2010
You can use --password-store=detect to get secure password storage in Gnome Keyring or KWallet. There's just an important bug having to do with accessing passwords after an upgrade but before restarting that isn't fixed yet, so it's not the default setting.
Thank you for your anwser. I've just tried --password-store=detect and it works. Passwords are stored in Gnome Keyring and not in the SQLite database anymore. I will test it in the next few days. I hope this option will become the default soon for users uncomfortable with the command line :) Thank you again for your help.
Comment 48 by mdm@chromium.org, Jan 6 2011
Labels: -MovedFrom-10 -Mstone-11 Mstone-10
Status: Fixed
Using GNOME Keyring / KWallet should be the default in the next dev channel. Not sure why bugdroid didn't post the commit: http://src.chromium.org/viewvc/chrome?view=rev&revision=70431
Project Member Comment 49 by bugdroid1@chromium.org, Jan 6 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=70431

------------------------------------------------------------------------
r70431 | mdm@chromium.org | Tue Jan 04 11:53:07 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profiles/profile_impl.cc?r1=70431&r2=70430&pathrev=70431

Linux: detect the native (encrypted) password store to use by default.
The basic, unencrypted store is still available with --password-store=basic.
BUG= 25404 
TEST=on gnome, kde 4, and probably xfce we should now use system-level stores
Review URL: http://codereview.chromium.org/3326010
------------------------------------------------------------------------
Project Member Comment 50 by bugdroid1@chromium.org, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 51 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Feature-Passwords -Area-Internals -Mstone-10 Cr-Internals Cr-UI-Browser-Passwords M-10
Project Member Comment 52 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment