I just read a couple of very interesting discussions on Chrome password security strategy.

Chrome’s insane password security strategy

Showing stored passwords - Tim Berners-Lee

The following is how Chrome, Firefox and Safari handle storing passwords and showing stored passwords:

Chrome uses OSX Keychain to store passwords in encrypted form. In Chrome, you can go to the password settings page and with one click you can see your passwords.

Firefox doesn't uses the OSX Keychain to store passwords in encrypted form. In Firefox, you have the option to use a Master Password (not enabled by default). You type the master password at the beginning of every new session and every time you want to view stored passwords.

Safari also uses the OSX Keychain to store passwords in encrypted form. However, in Safari when you want to see the passwords, you need to enter the KeychainLogin password. (It is a 'fake' measure, because Keychain doesn't actually require authenticated applications to enter the KeychainLogin password to retrieve the passwords stored by them. This can be seen when Safari retrieves the passwords on website login prompts without the need for KeychainLogin password.)

Given new sessions of Safari and Chrome and a malicious user who doesn't know the KeychainLogin password. Safari is, in effect, no secure than Chrome because the user can just change the type of the password field to text using the inspect element tool and see the password.

My question is:

1) Given an attacker who doesn't know the Firefox master password and a new Firefox session (which hasn't asked for the master password yet), how easy/hard is it to see the stored passwords?

2) If the firefox master password is different than the OS user account password, does knowing the user account password change anything?

I am asking this because in one of the above discussions the security tech lead of Chrome says:

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.

Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.

We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

  • 4
    I knew I was going to see this question about the outrage about nothing.
    – curiousguy
    Aug 26, 2013 at 2:59
  • Are you assume a "one strike" attack (you get once the control of the logged-in computer)? Can you come back? Can you install software?
    – curiousguy
    Aug 26, 2013 at 3:08
  • The attacker can install any software, browser extensions etc. but he needs to retrieve the passwords in one session i.e. before the original user comes back. I am wondering if there is a way which does not depend on the subsequent activities of the original user. Aug 26, 2013 at 3:43

2 Answers 2


There are two related but distinct issues here: that Chrome can retrieve passwords without extra authentication, and that it displays them upon request. Both Elliott Kember and Tim Berners-Lee confuse these issues.

That Chrome is able to retrieve passwords without prompting the user is inherent in using an operating system facility to store the passwords. It's up to the OS facility to arrange to authenticate the user or prompt for an authorization at the time the password is requested, or not. Encrypting stored passwords is no more the job of the browser than to provide file storage or a network stack: this is done by the operating system and benefits all applications, not just the one browser. Users can configure retention and access policies in the keychain application, and those settings can apply to items stored for applications other than Chrome (other browsers, network shared storage, FTP, SSH, PGP, …).

Tim Berners-Lee seems to be arguing for browsers to implement a password encryption feature on top of the operating system's. That's bogus: why would a browser do that? Firefox does it because Mozilla does it because Netscape does it because it was written for primitive operating systems that didn't have such a feature. There is also an advantage to the browser implementing its own password storage, which is that a profile can be copied between platforms complete with stored passwords. This is to be balanced by the downside of the browser implementing its own password storage, which breaks the expectations of users who believe that their secrets are protected by the operating system. If I'm entering passwords in OSX, I'd expect them to be stored in my keychain, protected by the same protection as the keychain (on-disk encryption with a master password, inaccessibility when the screen is locked, …). If my browser doesn't use this protection, that's an unexpected breach of trust from its part.

If a browser is to store passwords, it must be able to retrieve them. If the browser can retrieve them, so can any other application. So when Elliott Kember complains that “there’s no master password, no security”, this is plain nonsense. The passwords are already in the keychain, and any application can retrieve them. Chrome is not breaching any security here: it's honestly representing what information is available. Elliott Kember claims that the lack of choice is “deeply misleading”, but that's completely wrong: Chrome has no more choice to be able to access the passwords than you have a choice not to be able to hear when someone is telling you something in a loud voice. You may plug your ears and sing “lalalala” loudly, but that won't change the fact that you would be able to hear.

Elliott Kember acknowledges that “the computer is already insecure as soon as you have physical access” and “that’s just how password management works”. Well, precisely. Chrome is being transparent, which goes exactly against his claim that “Google isn’t clear about its password security”. Chrome is being perfectly honest: it can access the passwords and it does not hide this fact from users.

Elliott Kember is advocating for Chrome to provide users with a false sense of security. It is well-known that a false sense of security is the enemy of security. Justin Schuh has it right.

Tim Berners-Lee makes another point. He acknowledges that retrieving passwords is possible, and it can be done by downloading a simple application if none of the software installed on the computer can do it easily. However, he argues that this capability should not be made easily accessible in a legitimate-looking application, because that makes it look like looking at someone else's passwords is somewhat legitimate.

While this makes sense, it doesn't really hold water. If you're digging around somebody else's profile, you're clearly snooping. Somebody's password is no more confidential than their browsing history. Non-technical people are rather more prone to sharing their password than their browsing history, and that was already the case before Chrome.

The one security measure that Chrome should implement is not to risk accidentally disclosing passwords when the legitimate user is in control. And it's already doing that: you have to click a button to show each password.

So Chrome is doing it right. Keep doing what you're doing.

  • I agree with most of this, but I'm not entirely sure how a master password can lead to a false sense of security. If the stored passwords are encrypted with the master and the user dutifully closes the browser window when leaving the computer, what's vulnerable here? Oct 27, 2013 at 6:12
  • @Manishearth The user would have to close the browser process. Neither article mentions this important requirement, and who ever closes their browser anyway? And if you're worried about offline forensics and not just somebody accessing your session (for which screen locking will do nicely), then you need to be sure that the password will be wiped from memory and swap, which closing the browser doesn't do. Oct 28, 2013 at 0:06
  • You are advocating placing a lot of trust in the operating system. What if you reinstall Windows for some reason (but have backups, or don't reformat)? I dare say you won't be able to recover your old passwords from Chrome, but Firefox will be no problem. (for another example of unwarranted reliance on Windows, many websites refuse to load in Chrome on XP these days (google ERR_SSL_VERSION_OR_CIPHER_MISMATCH) because it uses Windows crypto libraries for HTTPS, whereas Firefox works just fine)
    – Hugh Allen
    Apr 15, 2016 at 11:02
  • @HughAllen If you reinstall your OS, you'd better have saved your data, including of course saved passwords. This is unrelated to your choice of browsers. Apr 15, 2016 at 11:29
  • I think Chrome uses CryptProtectData(). MS: "...only a user with logon credentials that match those of the user who encrypted the data can decrypt the data. In addition, decryption usually can only be done on the computer where the data was encrypted..." It's like when you reinstall Windows & can't access old files without "taking ownership". Would you want to read MSDN & the following link just to figure out whether you'll lose your data (& might get it wrong anyway): blogs.technet.microsoft.com/markrussinovich/2009/11/03/…
    – Hugh Allen
    Apr 16, 2016 at 6:39

Security best practice is that you should protect your computer account with a password, lock your screen when unattended, and never let anyone else use your account. If you follow this best practice, them Chrome's model makes a lot of sense. Your saved passwords are as secure as your user account - no more; no less.

Of course, in real life people do not follow this security best practice. Hence the desire to implement some technology to make your saved passwords more secure than your user account. There is some merit to this, but there is a major problem: If someone has access to your computer account, all bets are off. They can install malware that invisibly runs in the background, monitors everything you do, and allows the attacker remote control. Of course, to do this requires some degree of technical skill.

So ultimately the decision of whether to implement additional protections is a trade-off between protecting against unskilled attackers, and giving a false sense of security against skilled attackers. I don't think there is an absolute right or wrong here - both camps can justify their point of view.

To answer your specific questions:

1) If the attacker has access to the user's account (e.g. no screen lock) then moderately difficult. They need to install malware that will keylog the next password entry, and also extract the encrypted saved password file.

2) So, if the attacker doesn't have access to the user's account, then this depends how well the operating system protects that account. If the protection is rock solid, then the attacker simply cannot access the saved passwords.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .