How Browsers Store Passwords
Good information on how Internet Explorer, Chrome, and Firefox store user passwords.
Comments
Anura • January 8, 2015 5:50 PM
@edge
https://code.google.com/p/chromium/wiki/LinuxPasswordStorage
Chromium chooses which store to use automatically, based on your desktop environment.
Passwords stored in GNOME Keyring or KWallet are encrypted on disk, and access to them is controlled by dedicated daemon software. Passwords stored in plain text are not encrypted. Because of this, when either GNOME Keyring or KWallet is in use, any unencrypted passwords that have been stored previously are automatically moved into the encrypted store.
Support for using GNOME Keyring and KWallet was added in version 6, but using these (when available) was not made the default mode until version 12.
Thoth • January 8, 2015 8:25 PM
Security should be done in a boolean basis with no intermediate states. It either is secure or not secure and that’s it.
Firstly, if the browser is ever trusted (most people trust their browsers surprisingly), it is open to a wide variety of attack vectors and browsers are not engineered with security assurance from ground up but are simply sprinkled with the magic dust of vague security once in a while.
Mozilla’s efforts are admirable and the production of the NSS cryptolib is pretty good. I am wondering why so much attention are moved to OpenSSL when NSS could be tapped into and NSS is FIPS 140-2 capable in FIPS mode.
If a browser wants to store passwords, the vague idea of using some URL to hash for a password or key is a bad idea or setting the password/key to null/”” value is also not a good idea (which most of them do anyway). A browser should offer to act as a strong password manager or integrate with existing password managers or PKCS11 devices with proper authentication (user must choose a password or PIN consciously). If a browser stores passwords “automatically without authentication”, it is as good as close to plaintext and is useless.
So in essence, a browser should ask a user to setup a password management profile and take on the role as a password manager or delegate it to an actual password manager with plugins hooked into the browser and a profile is used (with proper authentication). If a user wants to store passwords without a proper authentication profile, it should simply reject the password management and fail gracefully.
Albertas • January 9, 2015 5:58 AM
@edge
In my setup, Chromium on Linux uses kwallet to store passwords. Kwallet is part of KDE and is designed specifically for this. It might be interesting to know what Chromium does when Kwallet or other such software is not available, because at least in the distro I use, there seems to be no dependency between Chromium and either password store.
Jim Jackson • January 9, 2015 6:27 AM
None of that has changed since that post was written in June of 2013?
Thursday, June 20, 2013
Ben • January 9, 2015 7:05 AM
The commentary is over-sensationalist.
In all cases, the password is stored encrypted in a way which will effectively prevent offline attacks if the master password is not known, and will effectively prevent online attacks by processes of other unprivileged users on the same machine.
In no case is the password stored in a way which will protect you if you have malware executing in the context of the current user. Because in the CryptProtectData case, that’s enough, and in the Firefox, or Chrome/Linux/KWallet case, because if they are running in your user context they can rob the master password in a number of different ways, that barely even qualify as hurdles.
Mace Moneta • January 9, 2015 11:02 AM
I always have my browser storage directories symlinked from ecryptfs, along with any other sensitive information (~/.ssh, ~/.gnupg, etc.). That way I don’t have to worry about weaknesses being found in one encryption or the other.
Anura • January 9, 2015 1:02 PM
@Albertas
See the link from my above post; if neither KWallet nor GNOME Keyring are available then it falls back to plaintext. They should really provide the ability to at least encrypt the data with a master password, but they do not.
uh, Mike • January 10, 2015 1:16 AM
My browser doesn’t save passwords because I don’t trust it for that.
J.L. • September 22, 2015 4:14 AM
that link is over 2 years old, how relevant is it to this day
i am using an internet key (through a net provider) pay as you go type.
when i started using it at the beginning it used to ask me for my sec pin number
before it would connect to the internet. Recently for no reason or action on my
part the usb key stopped asking for the pin number and now connects automatically
to a local LAN network. How has this happened as i am worried about security i would
prefer to type in a pin number as before and also why suddennly connected to a Lan?
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
edge • January 8, 2015 5:21 PM
Regarding Chrome, he’s got this – “We can finally see that the password given is encrypted using a call to the Windows API function CryptProtectData. ”
Anyone got additional details about how it’s done on non-windows platforms?