Security/Features/HighlightCleartextPasswords

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Status

Highlight Cleartext Passwords
Stage Draft
Status `
Release target `
Health OK
Status note `

Team

Product manager Sid Stamm
Directly Responsible Individual Tanvi Vyas
Lead engineer Tanvi Vyas
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks

Current/Latest Proposal:

  • See presentation: https://wiki.mozilla.org/images/5/5a/HighlightPasswordsPresentation.odp
  • Use an icon (ex: warning icon) in the password text box (shifting any placeholder the website set by a few pixels). This icon will appear all the time (not just onfocus). (Example Icon)
  • When the user clicks on the warning icon or focuses on the input box, a message pops up with text that interrupts the user (ex: doorhanger), "This will submit your password unencrypted/This is an unencrypted page." The dialog will be designed differently than other warnings, so that users don't ignore it out of habituation. The dialog will present the user with a choice.
    • If we can determine the ssl version of the page, provide these to options: "Click here to go to the encrypted version of this page." & "Click here to proceed stay on this page (not recommended)." Require the user to make a choice (no X to quit the dialog box)
    • If we cannot determine the ssl version of the page, the user does not have any choices to select from. The message will not pop up in this cases. A user can Learn more by clicking on the site identity button or clicking on the Warning Icon. We will recommend that the user not reuse a password that they also use on an important account on this site.
    • Perhaps include a checkbox for "Report to site owner".
    • Include a checkbox for "always redirect me".
  • Do not autocomplete username and password if it's saved in Password Manager (require the user to go through the multi-user experience in password manager).


Open Issues:

  • Should their be positive and negative assertions for type = password fields(ex: sad face and happy face) or only negative assertions?
    • Giving a positive security assertion might actually make users more worried. Ex: rent an apartment with bars on the windows, or without? People may question why there is a need for bars. Tendency towards being more afraid in the safer apartment with bars.
    • Examples: Green Plus and Red Minus
    • Positive assertion with be inconsistent - if the form action calls a javascript function, we will not know whether the post is over http or https, and hence can't give a positive or negative assertion. See here for an example.
  • How do we detect the fqdn of the https version of an http page (if it exists)? What percentage of pages will this cover?
    • Try just adding an s and check the status code in the response
    • Leverage data in password manager
    • Query http://foo.com/login.txt or https://foo.com/login.txt (similar concept to robots.txt). Websites create a login.txt that tells browser where to get the ssl version of a specific page.
    • SSL Observatory
  • Integration with Password Manager. If a page has a highlighted password field, should passwords automatically be populated by Password Manager? If don't autofill and the user wants the password autofilled anyway, how would they do that? What would the UX look like?
    • It would go through the multi-user experience (ex: when there are two username/password pairs stored for a site, the password isn't filled in until the user selects the username)
    • Should we set autocomplete=off for username and passwords?

Stage 1: Definition

1. Feature overview

Highlight passwords that are not transmitted over ssl. We will focus on type=password. Other sensitive information will be covered in https://wiki.mozilla.org/Security/Features/Identify_which_bits_are_unencrypted.

Goal of this feature is to educate users and developers when password fields are open to attack. Users are trained to visit the secure version of the login page (if one exists) when entering their password. Developers are pushed towards implementing secure login solutions for their users.

2. Users & use cases

  1. A user is asked to login on an http page. The login form submits to an http destination. Users password is sent in cleartext.
    • Highlight that the password field is insecure. Provide an option to visit the https version of the page if possible.
  2. A user is asked to login on an https page. The login form submits to an http destination. Users password is sent in cleartext.
    • Highlight that the password field is insecure.
    • Note that if the user hits submit in this case, the user will also get a Security Warning alert box.
  3. A user is asked to login on an http page. The login form submits to an https destination. An attacker can mitm the first request to the login page and replace the form with one that submits the password to the attackers webpage instead.
    • Highlight that the password field is insecure. Provide an option to visit the https version of the page if possible.
  4. A user is asked to login on an https page. The login form submits to an https destination. But the page includes active Mixed Script Content (scripts/css/etc).
    • Highlight that the password field is insecure. Provide the user an option to reload the page with mixed content blocked.
  5. A user is asked to login on an https page. The login form submits to an https destination. But the page includes Mixed Display Content (ex: images).
    • Do nothing
  6. A user is asked to login to an https page. The login form submit calls a javascript function. Hence, the form post may or may not be over https depending on the javascript.
    • Do nothing - This case may already be handled with a Security Warning alert box if the form posts over http. See hereand here

3. Dependencies

`

4. Requirements

When a webpage includes an input type=password field and the webpage does not offer a full ssl experience, indicate to the user that their unencrypted password may be accessible by eavesdroppers/attackers. Note that websites with non-ssl display-only content are an exception.

If there is a version of the insecure page that is available over ssl (and the browser is able to discover it) the user will be presented a link to the ssl page. The user can then decide if they'd like to login on the current page, or go to the ssl page to login. Caveats:

  • The browser will not know if the ssl page it links to is mixed content.
  • The browser will not know if the form post on the ssl page is over http - but the browser will notify the user that they are transmitting the data unencrypted - see here).
  • The browser CANNOT redirect the user automatically. The user may have never intended to login on that page, and we could end up DoS'ing sites that are not ready for the SSL load. (All firefox non-logged in users would visit the SSL page even if they don't have an account and don't want to login.)

The website SHOULD NOT be able to overwrite or replace the warning icon content.

Non-goals

This item is only for type=password. Other sensitive data is captured in this feature page: https://wiki.mozilla.org/Security/Features/Identify_which_bits_are_unencrypted

This feature does not prevent against active attacks (ex: man-in-the-middle on http pages).

Stage 2: Design

5. Functional specification

Phase 1: Use cases 1-3 - General case.

Phase 2: Use case 4 - Mixed Script Content. Blocked on bug 62178.

6. User experience design

Multiple options here. See Open Issues.

Stage 3: Planning

7. Implementation plan

https://bugzilla.mozilla.org/show_bug.cgi?id=748193

Phase 0: User Research. First on the password field itself, then later on how to redirect to the secure version of the site.

Phase 1: Use cases 1-3 - General case.

Phase 2: Use case 4 - Mixed Script Content.

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 P2
Rank 999
Theme / Goal Security Leadership
Roadmap Security
Secondary roadmap `
Feature list `
Project `
Engineering team Security

Team status notes

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


Additional Notes

https page with http form post:

  • chromes behavior: does nothing.
  • safari: warning text
    • "This is a non-secure form.
      This form will be sent in a way that is not secure. Are you sure you want to send it?"
    • Warning text appears on full https and mixed content pages.
  • firefox: warning text
    • "Security Warning: Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.
      Are you sure you want to continue sending this information?"
    • Warning text appears on full https and mixed content pages.

Test pages: https://people.mozilla.com/~tvyas/javascript_form_post.html https://people.mozilla.com/~tvyas/javascript_form_post_mixed.html

  • We can't handle use case 1 independently of use case 3. Because then sites in use case 1 will switch to use case 3. Then when we highlight for use case 3, the sites will have to change again.

Other Ideas:

  • In cases where you have logged in over https before, when you click on a username field, show a bubble that says "Or login securely" with a link.
  • Icon on right side of the password field that says "take me to the secure version". Ex: clicking unlock icon takes you the ssl version (if one exists). Otherwise, its not clickable.
    • Issue with this is that a user might accidentally click the icon and then wonder why they are being redirected.
  • Complete the first phase only for pages where you can login securely. So that there is something the user can do about it.
  • User has to hit the enter key twice to submit their password.  If they click login button then it just submits (no double click needed).  This might be good if the icon only shows up on focus (and hence the user might miss it).
  • If an https page has a form submit target that calls javascript, how do we determine whether the data is transmitted over http or https? The browser will not know until the submit button is hit and the password is already being sent. At that point, it is too late to highlight the password field in red. How can we analyze the javascript to determine that all eventual targets would be over https? Or should we just prompt a warning in these cases? Where would the warning go? We would have a high false positive rate. Should we ignore this case?
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Features/HighlightCleartextPasswords&oldid=768577"