canmove, Confirmed users
285
edits
Security/Features/PasswordManagerImprovements: Difference between revisions
Security/Features/PasswordManagerImprovements (view source)
Revision as of 19:54, 4 December 2014
, 4 December 2014no edit summary
No edit summary |
No edit summary |
||
| Line 11: | Line 11: | ||
|Feature users and use cases=* See https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver | |Feature users and 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 [http://arxiv.org/abs/1309.1416 "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. | * Includes improvements to the Password Manager to prevent attacks such as "Lupin" in the paper [http://arxiv.org/abs/1309.1416 "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 requirements= | |Feature requirements=i) Preventing active network attacks: | ||
*# Do not autofill the username/password stored in password manager on any pages. Provide alternative UX - <b>UX help needed</b>. 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.) | *# Do not autofill the username/password stored in password manager on any pages. Provide alternative UX - <b>UX help needed</b>. 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) | *#* For http sites (IE 11 has this security feature) | ||
| Line 24: | Line 24: | ||
*#* 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 (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. | *# 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. | ||
ii) 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). | ||
iii) 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 | ||
iv) 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>If we have to keep Autofill:</b> | ||
If we must allow autofilling in certain cases, then we also need the following security features: | 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). | * 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]. | * (platform work only) 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. | * (platform work only) Consider not autofilling in cases where the page has multiple login forms. | ||