Toolkit:Password Manager: Difference between revisions
(Update page for FF3 work planning.) |
(Add comments from Mike Beltzner.) |
||
| Line 6: | Line 6: | ||
* Improve code security and readability by porting to a JS component. | * Improve code security and readability by porting to a JS component. | ||
* Close out some of the [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=Password+Manager&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-01-01&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 237 open bugs] for Password Manager | * Close out some of the [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=Password+Manager&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-01-01&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 237 open bugs] for Password Manager | ||
* UI improvements | * UI improvements | ||
== Robustness to Site Changes == | == Robustness to Site Changes == | ||
| Line 48: | Line 48: | ||
* 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) | * 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) | ||
= | == UI Improvements == | ||
I asked Beltzner on IRC if he had any desired improvements, and came up with the following: | |||
* The "Should Firefox remember this password?" dialog shouldn't block the loading of the new page. | |||
* Password generation (eg, hash site name and a common password.) Has anti-phishing benefits because user doesn't even really know their own password. | |||
* Filter the list in the "Show Passwords" UI. (meaning?) | |||
* Password entry outside of content. InfoCard or something like it? | |||
* Simplify language (eg, remove "HTTP Password Required"). | |||
TBD. | TBD. | ||
Revision as of 22:12, 6 December 2006
Goals
- Add integration with OS X's Keychain
- Use MozStorage for on-disk file (instead of current weird text format)
- Implement some form of per-site password hashing (anti-phishing too?)
- Improve code security and readability by porting to a JS component.
- Close out some of the 237 open bugs for Password Manager
- UI improvements
Robustness to Site Changes
XXX - this text should be rolled into a (existing?) bug.
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)
UI Improvements
I asked Beltzner on IRC if he had any desired improvements, and came up with the following:
- The "Should Firefox remember this password?" dialog shouldn't block the loading of the new page.
- Password generation (eg, hash site name and a common password.) Has anti-phishing benefits because user doesn't even really know their own password.
- Filter the list in the "Show Passwords" UI. (meaning?)
- Password entry outside of content. InfoCard or something like it?
- Simplify language (eg, remove "HTTP Password Required").
TBD.