MozillaWiki

Security/Features/HighlightCleartextPasswords

< Security‎ | Features
Revision as of 20:52, 1 June 2012 by Tanvi (talk | contribs)
Please use "Edit with form" above to edit this page.

Status

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

{{#set:Feature name=Highlight Cleartext Passwords

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager Lucas Adamski
Directly Responsible Individual `
Lead engineer Tanvi Vyas
Security lead `
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=Tanvi Vyas |Feature security lead=` |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

Current/Latest Proposal:

  • 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. Perhaps add a recommendation about being careful if using a shared/open/public wifi network.
    • Perhaps include a checkbox for "Report to site owner".
  • 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:

  • What do we mean by "Highlight"?
    • On focus of password field, icon in the placeholder for all type=password input fields. Example
    • text in placeholder ("insecure", "sent unencrypted" "susceptible to eavesdropping", "page is unencrypted"etc.) Potentially different text depending on what the issues is on the page.
    • Text in the ToolTip when you mouseover the password field - Example of mouseover experience here.
    • Add information onmousover of submit button. (But what if the user hits enter)
    • Placeholder text is typically grey. Can it be another color?
    • Check if ssl version exists and if it does, offer a redirect.
    • Outline in a specific color. Red is already used for form validation. Maybe use another color with a constraint validation custom message.
  • 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 not automatically be populated by Password Manager? If we did this, and a user wanted 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 usernmae/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?
  • 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?

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 is mixed content because of 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 is mixed content because of 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 website SHOULD NOT be able to overwrite the "highlighted" content. (Example: if an insecure password field has an placeholder, our placeholder would overwrite the existing placeholder).

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: Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this is also on the feature page for Improvements to Password Manger.)

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

Phase 3: Use case 4 & 5 - Deal with mixed content. Blocked on bug 62178.

6. User experience design

Multiple options here. See Open Issues - "What do we mean by Highlight."

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: Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this may end up in a separate feature instead of part of Highlght Cleartext Passwords.)

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

Phase 3: Use case 4 & 5 - Deal with mixed 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

` {{#set:Feature open issues and risks=Current/Latest Proposal:

  • 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. Perhaps add a recommendation about being careful if using a shared/open/public wifi network.
    • Perhaps include a checkbox for "Report to site owner".
  • 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:

  • What do we mean by "Highlight"?
    • On focus of password field, icon in the placeholder for all type=password input fields. Example
    • text in placeholder ("insecure", "sent unencrypted" "susceptible to eavesdropping", "page is unencrypted"etc.) Potentially different text depending on what the issues is on the page.
    • Text in the ToolTip when you mouseover the password field - Example of mouseover experience here.
    • Add information onmousover of submit button. (But what if the user hits enter)
    • Placeholder text is typically grey. Can it be another color?
    • Check if ssl version exists and if it does, offer a redirect.
    • Outline in a specific color. Red is already used for form validation. Maybe use another color with a constraint validation custom message.
  • 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 not automatically be populated by Password Manager? If we did this, and a user wanted 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 usernmae/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?
  • 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?

|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. |Feature users and use cases=# 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 is mixed content because of 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 is mixed content because of 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

|Feature dependencies=` |Feature 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 website SHOULD NOT be able to overwrite the "highlighted" content. (Example: if an insecure password field has an placeholder, our placeholder would overwrite the existing placeholder). |Feature 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). |Feature functional spec=Phase 1: Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this is also on the feature page for Improvements to Password Manger.)

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

Phase 3: Use case 4 & 5 - Deal with mixed content. Blocked on bug 62178. |Feature ux design=Multiple options here. See Open Issues - "What do we mean by Highlight." |Feature 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: Do not autopopulate the username/password stored in password manager for http sites. Provide the multiuser experience seen here. (Note: this may end up in a separate feature instead of part of Highlght Cleartext Passwords.)

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

Phase 3: Use case 4 & 5 - Deal with mixed content. |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 P1
Rank 999
Theme / Goal Security Leadership
Roadmap Security
Secondary roadmap `
Feature list `
Project `
Engineering team Security

{{#set:Feature priority=P1

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

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


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 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.
  • 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).
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Features/HighlightCleartextPasswords&oldid=436784"