canmove, Confirmed users
285
edits
Security/Features/PasswordManagerImprovements: Difference between revisions
Security/Features/PasswordManagerImprovements (view source)
Revision as of 23:13, 8 January 2015
, 8 January 2015no edit summary
No edit summary |
No edit summary |
||
| Line 29: | Line 29: | ||
3) [https://bugzilla.mozilla.org/show_bug.cgi?id=1118553 Bug 1118553] Duplicate Passwords - Protecting users from password reuse attacks | 3) [https://bugzilla.mozilla.org/show_bug.cgi?id=1118553 Bug 1118553] 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 | ||
4) 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.) | 4) [https://bugzilla.mozilla.org/show_bug.cgi?id=1119555 Bug 1119555] 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.) | ||
<b>More about Autofill:</b> | <b>More about Autofill:</b> | ||
| Line 48: | Line 48: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 2.0 | * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 2.0 | ||
** 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] | ||