Security/Features/HighlightCleartextPasswords

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

{{#set:Feature product manager=Sid Stamm

|Feature feature manager=Tanvi Vyas |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:

• 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 redirect users to the secure version of the page
  • Site identity button (Larry)? https://wiki.mozilla.org/Privacy/Features/Improve_site_identity_button
  • Display info bar onfocus of pwd field
  • Clicking the icon in the placeholder
  • Link in the tooltips hint
  • Link in the constraint validation hint

• 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

` {{#set:Feature open issues and 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 redirect users to the secure version of the page
  • Site identity button (Larry)? https://wiki.mozilla.org/Privacy/Features/Improve_site_identity_button
  • Display info bar onfocus of pwd field
  • Clicking the icon in the placeholder
  • Link in the tooltips hint
  • Link in the constraint validation hint

• 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?

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

1. • 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

|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 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. |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: Use cases 1-3 - General case.

Phase 2: Use case 4 - Mixed Script Content. Blocked on bug 62178. |Feature ux design=Multiple options here. See Open Issues. |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: Use cases 1-3 - General case.

Phase 2: Use case 4 - Mixed Script 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	P2
Rank	999
Theme / Goal	Security Leadership
Roadmap	Security
Secondary roadmap	`
Feature list	`
Project	`
Engineering team	Security

{{#set:Feature priority=P2

|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 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).

• Overwriting placeholders or messing with the placeholder text that might be a label: "The placeholder attribute should not be used as an alternative to a label." See http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute

• 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?
  • This case is already be handled with a Security Warning alert box. See here and here.
  • Is there way to disable this security warning? Not currently: https://bugzilla.mozilla.org/show_bug.cgi?id=436200
  • Do you still get the warning if you are on a mixed content page?