Security/Features/PasswordManagerImprovements: Difference between revisions

Security/Features/PasswordManagerImprovements (view source)

1 byte added , 24 November 2014

no edit summary

canmove, Confirmed users

640

edits

@@ Line 54: / Line 54: @@
 ** 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]
 |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.
+*# Today the experience is that the user first has to type the username, and then the password will be filled in.<br>
-** 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
+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
 *# We could have an fill-and-submit option, so that there is still only one click for the user.  Instead of clicking "submit" they would click "fill and submit".  This way, we've added security without decreasing usability.
 *# To prevent clickjacking attacks, the UI for this could live somewhere in chrome; the user could interact with the some password manager directly instead of the webpage.