Toolkit:Password Manager

Goals

• improve the experience for existing password manager users
• make it easier to migrate passwords to Firefox from other browsers.

Firefox Storage

Firefox stores passwords with this metadata:

domain usernamefield passwordfield username password

Then uses the usernamefield/passwordfield values as hints to find the appropriate <input> elements within a webpage by matching them to the "name" attribute.

Unfortunately this means that when a website redesigns and changes the un/pw field names, the effect on the end user is that the password is "forgotten".

As a backup, when usernamefield/passwordfield fail to match, Password Manager should attempt to discover the password field manually, using a technique similar to what Camino uses.

This is needed for another reason - passwords stored by other browsers such as Camino and Safari are stored in the KeyChain WITHOUT username/password field hints - so un/pw field discovery must be manual.

Security heads up: Make sure that passwords are never restored into input fields which are hidden. Compare full domain name, do not do partial compares of domain names.

Mac OS X Integration

(See also bug 106400.)

Mac OS X provides an application called Keychain Services which manages passwords and certificates for all applications including web browsers. It provides default encryption of the passwords and certificates using the user's login password, locks and unlocks the chain per application etc. Basically everything we've had to re-implement for our password manager (including Master Password etc).

We should transition to using Keychain Sevices as the "out of the box" back end for storing passwords and certificates. This will allow users transitioning from Safari and Camino to bring across their site passwords in addition to their Bookmarks, Preferences and other data for the optimal user experience.

We should retain the existing back end in code for Windows and Linux, and for Mac OS X 1.0 users who have established password and certificates collections. We need some heuristic for detecting whether or not Firefox is the default browser, has an established password collection etc so we can determine which back end to use.

We might also offer a hidden pref to let users toggle between the two in case the heuristic breaks down.

The integration is very simple - where we retrieve password and certificate data from our password and certificate store now, we alternate on some preference value ("use keychain") - if not, use the old way, if so, call SecKeychainFindInternetPassword to get the value.

By keeping the integration at this very low level we can minimize the impact of the changes and retain the functionality that Firefox users expect - dropdown showing choice of options (multiple options can be stored in our signons file - we just don't store the passwords and certificates there) - we can even add metadata (username/password field name attribute values) when we discover them to the signon file, which at that point just becomes a metadata storage point.

Dependencies

Two dependencies for Keychain Services integration on Mac OS X:

• the ability to open Keychain Services from Preferences (add a method or constant to nsI*ShellService)
• the ability to detect if default browser (implemented on Windows but not MacOS X) (this may prove challenging in addition since nsIShellService is a browser API, not a toolkit one where password manager lives. Maybe it should move, or become more generic)

Work Estimate

2 weeks