Security/Features/PasswordManagerImprovements

From MozillaWiki
< Security‎ | Features
Revision as of 23:15, 10 November 2014 by Tanvi (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Security Improvements to Password Manager
Stage Draft
Status `
Release target `
Health OK
Status note `

{{#set:Feature name=Security Improvements to Password Manager

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature 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 `

{{#set:Feature product manager=`

|Feature feature manager=` |Feature lead engineer=` |Feature security lead=Tanvi Vyas |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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
  • Include 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

  • Preventing active network attacks:
    1. Do not autofill the username/password stored in password manager in certain situations (listed below). Provide alternative UX - UX help needed
      • 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)
    2. Highlight Cleartext Passwords.) - Warn users about entering their passwords on insecure pages - Bug 759860. UX help needed for this.
    3. Secure Filling - 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.
  • 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).
  • Duplicate Passwords - Protecting users from password reuse attacks
    • If an identical password is stored for both any http site and any https site (not necessarily same domain), and it is not used on the http site for X months, expire the http version. (This helps in cases where the hostname has changed, e.g. from mail.google.com to www.google.com.) If the http site and the https site are same domain, we can expire the http password in <X months (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).
  • 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. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive the STS storage.)

Further ideas/thoughts that are not fully investigated yet.

  • Assume we have implemented secure filling (javascript on the page can't read the password). If the user prompts the password manager to fill in a password on an HTTP page and the form action has changed since the password was stored, don't send the password (might be tricky to implement). Perhaps with an UI for user override. (There are secure autofilling issue with ajax logins, a technique used mostly in china per https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver)
  • If we don't allow javascript access to all password fields, could javascript on the page still grab key strokes?
  • Working on the credential management spec can help us in the long run with password detection and secure filling.
  • Consider not autofilling passwords in following cases.
    1. If there are multiple login forms on a page??
    2. If the form action has changed since the password was stored. (To do this, we need to include the form action in the key, along with the url. We'd need to check the action both on load and on submit. What if it's a javascript action? More investigation needed here.)
  • More on HSTS - 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. (Potential privacy issue)
  • 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.
  • 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

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

  • What should the UX be when we do not autofill?
    1. Today the experience is that the user first has to type the username, and then the password will be filled in.
    2. We could have an autofill-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.
    3. 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.
  • 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).

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

` {{#set:Feature open issues and risks=` |Feature overview=Hardening the Password Manager. |Feature users and use cases=* See https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver

  • Include 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 dependencies=` |Feature requirements=* Preventing active network attacks:

    1. Do not autofill the username/password stored in password manager in certain situations (listed below). Provide alternative UX - UX help needed
      • 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)
    2. Highlight Cleartext Passwords.) - Warn users about entering their passwords on insecure pages - Bug 759860. UX help needed for this.
    3. Secure Filling - 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.
  • 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).
  • Duplicate Passwords - Protecting users from password reuse attacks
    • If an identical password is stored for both any http site and any https site (not necessarily same domain), and it is not used on the http site for X months, expire the http version. (This helps in cases where the hostname has changed, e.g. from mail.google.com to www.google.com.) If the http site and the https site are same domain, we can expire the http password in <X months (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).
  • 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. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive the STS storage.)

Further ideas/thoughts that are not fully investigated yet.

  • Assume we have implemented secure filling (javascript on the page can't read the password). If the user prompts the password manager to fill in a password on an HTTP page and the form action has changed since the password was stored, don't send the password (might be tricky to implement). Perhaps with an UI for user override. (There are secure autofilling issue with ajax logins, a technique used mostly in china per https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver)
  • If we don't allow javascript access to all password fields, could javascript on the page still grab key strokes?
  • Working on the credential management spec can help us in the long run with password detection and secure filling.
  • Consider not autofilling passwords in following cases.
    1. If there are multiple login forms on a page??
    2. If the form action has changed since the password was stored. (To do this, we need to include the form action in the key, along with the url. We'd need to check the action both on load and on submit. What if it's a javascript action? More investigation needed here.)
  • More on HSTS - 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. (Potential privacy issue)
  • 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.
  • 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

|Feature non-goals=` |Feature functional spec=` |Feature ux design=* What should the UX be when we do not autofill?

    1. Today the experience is that the user first has to type the username, and then the password will be filled in.
    2. We could have an autofill-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.
    3. 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.
  • 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).

|Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority Unprioritized
Rank 999
Theme / Goal `
Roadmap Security
Secondary roadmap `
Feature list `
Project `
Engineering team `

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Features/PasswordManagerImprovements&oldid=1032207"