Toolkit:Password Manager: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Mnoorenberghe moved page Firefox:Password Manager to Toolkit:Password Manager: Password manager is in Toolkit)
(Removing obsolete content)
Line 1: Line 1:
= Goals =
The Toolkit password manager is responsible for remembering usernames and passwords on sites and allowing the user to autofill or autocomplete it upon returning to the website.


* Add integration with OS X's Keychain
=== Mac OS X Integration ===
* 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 [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
 
== 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=106400 bug 106400], [https://bugzilla.mozilla.org/show_bug.cgi?id=496660 bug 496660].)
(See also [https://bugzilla.mozilla.org/show_bug.cgi?id=106400 bug 106400], [https://bugzilla.mozilla.org/show_bug.cgi?id=496660 bug 496660].)
Line 41: Line 17:
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.
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 ===
==== Dependencies ====


Two dependencies for Keychain Services integration on Mac OS X:
Two dependencies for Keychain Services integration on Mac OS X:
Line 48: Line 24:
* 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 ==
== Existing Extensions in 2009 ==
 
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 or search functionality in the list in the "Show Passwords" dialog box. When passwords rise over 100, it becomes difficult to find a specific password.
* Password entry outside of content. InfoCard or something like it?
* Simplify language (eg, remove "HTTP Password Required").
TBD.
 
= Existing Extensions =


The following password-management extensions are on addons.mozilla.org, and give some indication of what kind of features people find useful.
The following password-management extensions are on addons.mozilla.org, and give some indication of what kind of features people find useful.
Line 82: Line 47:
* [https://addons.mozilla.org/firefox/670/ Password Composer] 6
* [https://addons.mozilla.org/firefox/670/ Password Composer] 6
* [https://addons.mozilla.org/fr/firefox/addon/4133 Password Finder] ?
* [https://addons.mozilla.org/fr/firefox/addon/4133 Password Finder] ?
== See Also ==
{{subpagelist}}
[[Firefox:Password_Manager:UI]]
[https://bugzilla.mozilla.org/buglist.cgi?component=Password%20Manager&product=Toolkit&bug_status=__open__ Bug List]
[https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Password%20Manager File a bug]

Revision as of 18:49, 1 June 2015

The Toolkit password manager is responsible for remembering usernames and passwords on sites and allowing the user to autofill or autocomplete it upon returning to the website.

Mac OS X Integration

(See also bug 106400, bug 496660.)

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)

Existing Extensions in 2009

The following password-management extensions are on addons.mozilla.org, and give some indication of what kind of features people find useful.

See Also

Firefox:Password_Manager:UI

Bug List File a bug

Retrieved from "https://wiki.allizom.org/index.php?title=Toolkit:Password_Manager&oldid=1077740"