Security/Features/PasswordManagerImprovements: Difference between revisions

|Feature requirements=1) Preventing active network attacks:

* Do not autofill the username/password stored in password manager on any pages. Provide alternative UX - <b>UX help needed</b>.  If automatically filling the password must be an option, then at least do not fill in the following cases.  (Note this does not secure the user from xss attacks, third party javascript, etc.)

** For http sites (IE 11 has this security feature)

** https sites that have mixed active content

** https sites that require a cert override (chrome does this)

** in iframed sites (where the parent and frame are not  same orign, or always?) (safari does this for non-same origin, chrome does this for all frames). (Open Issue - what about third party widgets that allow users to login and post comments.)

** Invisible form fields (visibility and opacity, although this isn't going to prevent clickjacking attacks to autofill the passwords)

* Warn users when they are entering their passwords on HTTP sites. UX help needed for this. Some options:

** warning icon in the password field

** Fill-and-submit button is a different color

** On mouseover of the fill in submit button, the user can read a tooltip that warns them that their password can be seen in the clear.

** See also [https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords Highlight Cleartext Passwords] and [https://bugzilla.mozilla.org/show_bug.cgi?id=759860 Bug 759860].

* Secure Filling (platform work only) - Passwords that are saved by the password manager should not be available to javascript on the page.  The actual password values should only be sent on submit.  This protects the password from attacks via xss, 3rd party javascript, etc.  Implementation details: when a password is filled in on a form, fill hash(uri, username, salt) instead of the actual password.  On submit, lookup the actual password value for that url and send that instead.  Username is included for cases where there are multiple usernames.

2) Preventing local attacks:

* Explore solutions for encrypting the passwords stored locally in the password manager (for example, make use of keychain or encryption mechanisms that come with the OS).

3) Duplicate Passwords - Protecting users from password reuse attacks

* Create UI around alerting users that they are reusing the same passwords

4) HSTS (platform work only): If a site is HSTS, then there is no reason to have http data for that site. Hence, if a site is marked HSTS, and the user has any data (cookies, passwords, etc) that are not https-only/secure, immediately mark that data as https-only. (Note that we'd need some way to indicate that the site has been STS for at least X weeks to prevent deleting data from a site that goes HSTS as a beta test and then goes back to non-HSTS.)