Security/Features/PasswordManagerImprovements: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 11: Line 11:
|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 [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].) - https://bugzilla.mozilla.org/show_bug.cgi?id=759860
|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].) - https://bugzilla.mozilla.org/show_bug.cgi?id=759860
# Do not give javascript access to password fields.  Javascript would just be able to determine the length of the password (browser fills in dummy values for each * in the password field).  The actual password the user enters is only used on submit.  (This becomes a problem for password strength indicators).  https://bugzilla.mozilla.org/show_bug.cgi?id=653132
# If a site is marked STS by a website (or by a user with ForceTLS or by the browser pinned list), 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 by a website (or by a user with ForceTLS or by the browser pinned list), 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.)

Revision as of 17:20, 21 October 2014

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 Lucas Adamski
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=Lucas Adamski

|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

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.

2. Users & use cases

  1. 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 Highlight Cleartext Passwords.) - https://bugzilla.mozilla.org/show_bug.cgi?id=759860
  2. Do not give javascript access to password fields. Javascript would just be able to determine the length of the password (browser fills in dummy values for each * in the password field). The actual password the user enters is only used on submit. (This becomes a problem for password strength indicators). https://bugzilla.mozilla.org/show_bug.cgi?id=653132
  3. If a site is marked STS by a website (or by a user with ForceTLS or by the browser pinned list), 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.)
  4. 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.)
  5. If an identical password is stored for both any http site and any https site, and it is not used on the http site for 16 months, expire the http version. (This helps in cases where the hostname has changed, e.g. from mail.google.com to www.google.com, and the security level has also changed.)
  6. Don't autofill passwords within frames (similar to the Safari browser's password manager).
    • Open Issue - what about third party widgets that allow users to login and post comments.
  7. If an identical password is stored for the both the http and https version of a site, prompt the user to redirect to the https site. (Couldn't we do this even if the passwords are not identical?)
  8. 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.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

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=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 Highlight Cleartext Passwords.) - https://bugzilla.mozilla.org/show_bug.cgi?id=759860

  1. Do not give javascript access to password fields. Javascript would just be able to determine the length of the password (browser fills in dummy values for each * in the password field). The actual password the user enters is only used on submit. (This becomes a problem for password strength indicators). https://bugzilla.mozilla.org/show_bug.cgi?id=653132
  2. If a site is marked STS by a website (or by a user with ForceTLS or by the browser pinned list), 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.)
  3. 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.)
  4. If an identical password is stored for both any http site and any https site, and it is not used on the http site for 16 months, expire the http version. (This helps in cases where the hostname has changed, e.g. from mail.google.com to www.google.com, and the security level has also changed.)
  5. Don't autofill passwords within frames (similar to the Safari browser's password manager).
    • Open Issue - what about third party widgets that allow users to login and post comments.
  6. If an identical password is stored for the both the http and https version of a site, prompt the user to redirect to the https site. (Couldn't we do this even if the passwords are not identical?)
  7. 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.

|Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |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=` }}