Personal tools

Security/Features/PasswordManagerImprovements

From MozillaWiki

Jump to: navigation, 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 `

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 `

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. 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.)
  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 both any http site and any https site, prompt the user to redirect to the https site.
  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.

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

`


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 ` `