Google Chrome and master passwords

Master passwords for browsers provide a measure of security against some common, if weak, attack vectors. Firefox has had master passwords for some time, but Google's Chrome browser does not, nor does it seem to have any kind of priority to be added. That makes some users rather unhappy, to the point of saying that they won't use the browser until it is implemented. Google's position seems to be that master passwords only provide an illusion of security, but that is an oversimplification.

The idea behind a master password is to protect the credentials (username and password) for accessing web sites that are stored by the browser. The master password is required to unlock (really decrypt) the credential storage before the browser can auto-fill login forms. Without a master password, Firefox stores credential information unencrypted on the disk. Chrome does encrypt the credentials using the user's session information—but only on Windows—for Linux it stores them unencrypted.

As Jamie Strandboge describes in a blog posting, it is trivial to extract the credentials stored by Chrome on Linux in a SQLite database file. A bug filed against Chrome in September 2008 requests adding a master password, and, while it has seen many comments, it has also seen little action on the part of the Chrome developers. For Linux users, it is pretty clear that leaving an unencrypted version of all stored passwords on the disk is a security hole; it definitely requires access to the data, either on the machine itself or elsewhere—like a network share or backup of the home directory. Ways to get that access aren't very hard to envision. Since the data is encrypted on Windows, the picture there is a little murkier.

It is certainly true that anyone who gets physical access to your machine can do an amazing amount of harm to it if they want to. But it is also true that many people allow their computer to be used by others to do a quick search or check email. Those uses are typically short in duration and are "semi-supervised" in the sense that the owner is often around and might very well notice someone installing a keylogger or running some kind of password cracker. What may escape notice is someone using the browser interface in fairly standard ways—to look at stored passwords for example.

The answer, according to Chrome developer Peter Kasting is to "lock your desktop (it's two keys!) or close Chrome" if you don't trust those with physical access. Essentially, because of the way Chrome is implemented, there is no secure way to allow someone to use your open browser session—or even to start a new one for them to use. With Firefox, one can start a new browser and not provide the master password (or just log out of the "Software Security Device"), which will allow semi-untrusted users to jump on and do a quick Google—or check Gmail.

Given the sensitivity of stored passwords—though many sensitive web sites, like banks and brokerages, have started disallowing credential storage—a master password protecting them gives users a sense of protection. It may well be that the average user overestimates the amount of protection that a master password provides, but that doesn't mean it provides no protection. There is certainly a big difference between a sophisticated hacker willing to risk jail time by installing a keylogger and a "friend" who thinks it would be funny to update your Facebook status for you. The latter is likely to be thwarted by a master password.

It is a bit hard to understand why the Chrome developers are so unwilling to consider adding the feature. It shouldn't be particularly difficult in a technical sense. The "UI complexity" argument rings a little hollow. The lack of any way to get password encryption on Linux just seems like a bug that needs to be fixed, though there isn't any real indication that it will be. Maybe someone in the community needs to take a crack at it—it is, after all, free software.