Security/Features/PasswordManagerImprovements: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 23: Line 23:
*#* 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.
*#* 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].
*#* 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 - 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.
*# 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.
* Preventing local attacks:
* 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).
** 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).
* Duplicate Passwords - Protecting users from password reuse attacks
* Duplicate Passwords - Protecting users from password reuse attacks
** Create UI around alerting users that they are reusing the same passwords
** Create UI around alerting users that they are reusing the same passwords
* HSTS: 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.)
* 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.)


<b>Autofill:</b>
<b>Autofill:</b>
Line 41: Line 41:
<b>Future Work:</b>
<b>Future Work:</b>


* Support [https://mikewest.github.io/credentialmanagement/spec/ Credential Management Specification] so websites can opt into better detection and protection.
* Support [https://mikewest.github.io/credentialmanagement/spec/ Credential Management Specification] so websites can opt into better detection and protection (platform work only).


* Prefer secure origins - If a password is stored in an http version of a site, see if the https version exists.  If it does, prompt the user to redirect to the https version of the site and store their password there instead. (Issue here is that we don't always know if changing the url to https will work, or if a site is set up to have a different domain or path for their secure version)
* Prefer secure origins - If a password is stored in an http version of a site, see if the https version exists.  If it does, prompt the user to redirect to the https version of the site and store their password there instead. (Issue here is that we don't always know if changing the url to https will work, or if a site is set up to have a different domain or path for their secure version)
Line 53: Line 53:
* Assume we have implemented secure filling (javascript on the page can't read the password).  If the user prompts the password manager to fill in a password on an HTTP page and the form action has changed since the password was stored, don't send the password (might be tricky to implement).  Perhaps with an UI for user override. (Secure autofilling causes issues with ajax logins, a technique used mostly in china per https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver)
* Assume we have implemented secure filling (javascript on the page can't read the password).  If the user prompts the password manager to fill in a password on an HTTP page and the form action has changed since the password was stored, don't send the password (might be tricky to implement).  Perhaps with an UI for user override. (Secure autofilling causes issues with ajax logins, a technique used mostly in china per https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver)


* Secure Filling 2.0
* Secure Filling 2.0 (platform work only)
** Do not give javascript access to any password fields (regardless of whether the password manager saves the password) - the actual password the user enters is only used on submit.  The problem with this is with registration pages that use javascript to test the password strength.  [https://bugzilla.mozilla.org/show_bug.cgi?id=653132 Bug 653132].  Can we detect registration pages?  If a page a registration page has only one password field (they don't ask you to confirm your password by entering it twice) do they really use javascript to test password strength?  Since they aren't asking you to confirm your password, they probably aren't too concerned with special characters.
** Do not give javascript access to any password fields (regardless of whether the password manager saves the password) - the actual password the user enters is only used on submit.  The problem with this is with registration pages that use javascript to test the password strength.  [https://bugzilla.mozilla.org/show_bug.cgi?id=653132 Bug 653132].  Can we detect registration pages?  If a page a registration page has only one password field (they don't ask you to confirm your password by entering it twice) do they really use javascript to test password strength?  Since they aren't asking you to confirm your password, they probably aren't too concerned with special characters.
|Feature ux design=* What should the UX be when we do not autofill?
|Feature ux design=* What should the UX be when we do not autofill?
*# Today the experience is that the user first has to type the username, and then the password will be filled in. [NB: it fails utterly on "password-only" forms (where the username is known to the site already, such as by a cookie) because there's no username field interaction to trigger the fill-in]
*# Today the experience is that the user first has to type the username, and then the password will be filled in. [NB: it fails utterly on "password-only" forms (where the username is known to the site already, such as by a cookie) because there's no username field interaction to trigger the fill-in]
canmove, Confirmed users
285

edits

Navigation menu