This has come up in discussions I've had with a number of people as a way to secure passwords a bit better, so I'm filing the bug. By default we don't set a master password & users passwords are exposed with little effort (bug 259996 is WONTFIX). I don't have any numbers to support this, but I would assume that _most_ users don't set a master password. So I'm proposing we generate a master password & store it in the keychain for the user. The user will then be prompted with a system UI to "unlock" Firefox/TB/SM. Another option is to actually store all passwords in keychain (bug 106400) but that could limit what we can do. Already we're storing a GUID for each entry, and as far as I can tell from the Apple Dev docs, you can't store arbitrary fields with keychain items. (using SecKeychainAddInternetPassword) SecKeychainItemCreateFromContent might work, but docs say to use InternetPassword or GenericPassword for password data, so I'm not sure if it would get encrypted. So by generating a random password & storing that in keychain we gain some level of security for all (Mac) users. We would use the GenericPassword mechanism to setting the username to the application (Firefox, Thunderbird, Seamonkey). Users would be prompted for their keychain password the first time we need to encrypt/decrypt anything. In theory this shouldn't have to change any code in the password manager. It can presumably be shoved in front of the SecretDecoderRing stuff so that it happens before a call to encryptString, etc. Ideally a solution would be found that works cross platform, otherwise I fear this has has no chance of happening - there would be too much different code to maintain (preferences UX would change, behavior wouldn't be consistent, etc).

Good idea, this would solve the most annoying problem with the current Password Manager implementation on Mac: The Master Password requester.

See also bug #309807 regarding storing individual passwords (not master password) in the case of Gnome.

I'm generally for storing passwords, certificates etc. in the OS keychain (no matter if Mac, Gnome or KDE). There are several reasons: 1. Convenience Especially for certificates: Say a company uses its own CA and installs client certificates in the keychain. Now that works out of the box with Safari on Mac or Konqueror on KDE... But you have to install them separately for Firefox. Just having a master password in the keychain won't help here. 2. Security I think having a separate master password lowers security, because this leaves users only two bad options: Option A) They choose the same password as the login password and as the master password for Firefox. Not such a good idea. If an attacker manages to find out the master password, he also has the login password. Plus, end users probably have no idea, what algorithm Firefox uses to encrypt its password store (I don't know - what algorithm does it use? How many bits?) Option B) They choose a different password for the login password and the master password for Firefox. In practice, not such a good idea either: The more passwords users have to remember, the shorter and simpler passwords they choose. But it's way better to have one strong password than two not-so-strong passwords. So ideally, users would have a very strong login password for their account, and use that password to give access to their keychain.

On Windows, the CryptProtectData and CryptUnprotectData APIs can be used for secure local storage. http://msdn.microsoft.com/en-us/library/aa380261%28v=VS.85%29.aspx

Did someone change something? I am using Thunderbird in a triple boot environment Ubuntu-Windows7-MacOSX10.6.8 with a shared profile on a NTFS partition that all OSes can read. (b.t.w. only Thunderbird can do that magic!) It worked pretty well until i updated to my current Version 9.0.1. Now when I run TB on OSx I must reenter the newsgroups user and password, which is not stored in the keychain _after I have used TB on an other OS_. It is stored across a reboot as long as I stay on OSx, but any usage of Ubuntu or Windows seems to kill the ability to retrieve the authorization data from the keychain. The problem is specific to OSX only, on Linux and on Windows it works. The problem is new to the last TB version. The keychain information on Mail accounts is OK, the regression impacts only newsgroups... Strange, isn't it? Have ou got a cure?

It's generally agreed among UX/Engineering/Product that we don't want to further develop the existing master password functionality, as it's a poor fit for current needs and our current direction in this area.

(In reply to Justin Dolske [:Dolske] from comment #6) > It's generally agreed among UX/Engineering/Product that we don't want to > further develop the existing master password functionality, as it's a poor > fit for current needs and our current direction in this area. So what are the current needs and direction?