Security/Features/PasswordManagerImprovements: Difference between revisions

Jump to navigation Jump to search
no edit summary
m (moved PasswordManagerImprovements to /Security/Features/PasswordManagerImprovements: I just created this. Should have been under /Security/Features)
No edit summary
Line 10: Line 10:
{{FeaturePageBody
{{FeaturePageBody
|Feature overview=Improvements to the Password Manager to prevent attacks such as "Lupin" in the paper "Automated Password Extraction Attack on Modern Password Managers".  When a user is on an insecure network and makes any http request, a mitm could add login iframes to the http request.  The mitm can then add javascript to the responses from the login pages that send the attacker the autocompleted passwords from password manager.
|Feature overview=Improvements to the Password Manager to prevent attacks such as "Lupin" in the paper "Automated Password Extraction Attack on Modern Password Managers".  When a user is on an insecure network and makes any http request, a mitm could add login iframes to the http request.  The mitm can then add javascript to the responses from the login pages that send the attacker the autocompleted passwords from password manager.
|Feature users and use cases=# Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this is also in the feature page for [https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords Highlight Cleartext Passwords].)
|Feature users and use cases=# Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen [https://people.mozilla.com/~tvyas/multiuser_experience.jpg here]. (Note: this is also in the feature page for [https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords Highlight Cleartext Passwords].)
# If a site is marked STS but a website (or by a user with ForceTLS), then there is no reason to have http data for that site. Hence, if a site sends an STS header, and the user has any data (cookies, passwords, etc) that are not https-only/secure, immediately mark that data as https-only. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive the STS storage.)
# If a site is marked STS but a website (or by a user with ForceTLS), then there is no reason to have http data for that site. Hence, if a site sends an STS header, and the user has any data (cookies, passwords, etc) that are not https-only/secure, immediately mark that data as https-only. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive the STS storage.)
# When clearing history, retain the STS bit if any other data associated with the site is retained. For example, in the common case of clearing all history other than passwords, retain the STS bits for sites that have passwords stored. (This accomplishes roughly the same thing as #1.)
# When clearing history, retain the STS bit if any other data associated with the site is retained. For example, in the common case of clearing all history other than passwords, retain the STS bits for sites that have passwords stored. (This accomplishes roughly the same thing as #1.)
Line 18: Line 18:
# If an identical password is stored for both any http site and any https site, prompt the user to redirect to the https site.
# If an identical password is stored for both any http site and any https site, prompt the user to redirect to the https site.
# 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.
# 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.
}}
}}
{{FeatureInfo
{{FeatureInfo
canmove, Confirmed users
285

edits

Navigation menu