Security/Features/PasswordManagerImprovements: Difference between revisions
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]. | ** See also [https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords Highlight Cleartext Passwords]. | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 1.0 | * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 1.0 - 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: | 2) Preventing local attacks: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1118549 Bug 1118549] Encryption - 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). | * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118549 Bug 1118549] Encryption - 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) [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 | 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.) | ||
<b>Autofill:</b> | <b>Autofill:</b> | ||
Line 34: | Line 34: | ||
* If an identical password is stored for both the http version and https version of a specific website (or domain), and it is not used on the http site for X months, expire the http version after alerting the user. (This can help in cases where the website has upgraded to https, but the user's http password manager entry still exists and is open to attack). | * If an identical password is stored for both the http version and https version of a specific website (or domain), and it is not used on the http site for X months, expire the http version after alerting the user. (This can help in cases where the website has upgraded to https, but the user's http password manager entry still exists and is open to attack). | ||
* | * When the password field name is different from the name when the password was saved, don't allow filling & submit. Moreover, don't allow javascript to dynamically change the name of the form?? See [https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-silver.pdf section 5.2, Preventing self exfiltration attacks]. | ||
* | * Consider not autofilling in cases where the page has multiple login forms. | ||
<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. | ||
* 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) | ||
* [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. | ||
Line 51: | Line 51: | ||
<b>Investigate more:</b> | <b>Investigate more:</b> | ||
* Only autofill forms after user interaction with the login page, not necessarily the form - https://code.google.com/p/chromium/issues/detail?id=257156. We need more details here. | * Only autofill forms after user interaction with the login page, not necessarily the form - https://code.google.com/p/chromium/issues/detail?id=257156. We need more details here. | ||
|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] |
Revision as of 01:09, 7 January 2015
Status
Security Improvements to Password Manager | |
Stage | Draft |
Status | ` |
Release target | ` |
Health | OK |
Status note | ` |
Team
Product manager | ` |
Directly Responsible Individual | ` |
Lead engineer | ` |
Security lead | Tanvi Vyas |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | ` |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Hardening the Password Manager.
2. Users & use cases
- See https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver
- Includes 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.
3. Dependencies
`
4. Requirements
1) Preventing active network attacks:
- Bug 1118511 Do not autofill the username/password stored in password manager on any pages. Provide alternative UX - UX help needed. 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)
- Bug 748193 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 Highlight Cleartext Passwords.
- Bug 1118540 Secure Filling 1.0 - 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:
- Bug 1118549 Encryption - 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) Bug 1118553 Duplicate Passwords - Protecting users from password reuse attacks
- 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.)
Autofill: If we must allow autofilling in certain cases, then we also need the following security features:
- If an identical password is stored for both the http version and https version of a specific website (or domain), and it is not used on the http site for X months, expire the http version after alerting the user. (This can help in cases where the website has upgraded to https, but the user's http password manager entry still exists and is open to attack).
- When the password field name is different from the name when the password was saved, don't allow filling & submit. Moreover, don't allow javascript to dynamically change the name of the form?? See section 5.2, Preventing self exfiltration attacks.
- Consider not autofilling in cases where the page has multiple login forms.
Future Work:
- Support Credential Management Specification so websites can opt into better detection and protection.
- 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)
- 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. 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.
Investigate more:
- Only autofill forms after user interaction with the login page, not necessarily the form - https://code.google.com/p/chromium/issues/detail?id=257156. We need more details here.
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience 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]
- 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. Clickjacking is not our biggest threat here though, so in content would be okay too.
- What should the UX be when we alert users of duplicate passwords?
- Can we somehow expose the about:config option signon.autofill to users to prevent attacks on saved passwords in HTTPS pages (ex: XSS bugs on the victim site). Alternatively, if we come up with a fill-and-submit that is more usable than autofill, we can deploy it on both HTTP and HTTPS pages.
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | Unprioritized |
Rank | 999 |
Theme / Goal | ` |
Roadmap | Security |
Secondary roadmap | ` |
Feature list | ` |
Project | ` |
Engineering team | ` |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |