MozillaWiki

Security/Features/HighlightCleartextPasswords

< Security‎ | Features
Revision as of 19:11, 26 April 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

  • What do we mean by "Highlight"?
    • icon in the placeholder for all type=password (ex: lock and unlock)
    • 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
    • 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.
  • 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?
  • If an https page has a form submit target that call is 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 may already be handled with a Security Warning alert box. See people.mozilla.com/~tvyas/https_post_http.png and people.mozilla.com/~tvyas/https_post_http_with_js.png
    • 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?

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

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.
  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.
  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.
  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 people.mozilla.com/~tvyas/https_post_http.png and people.mozilla.com/~tvyas/https_post_http_with_js.png

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 unecrypted password may be accessible by eavesdroppers/attackers. Note that websites with non-ssl display-only content are an exception.

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

Stage 2: Design

5. Functional specification

Phase 1: Use cases 1-3 - General case. (Considering adding a phase and including Use Case 3 in Phase 1b.)

Phase 2: Use case 4 & 5 - Deal with mixed content.

Phase 3: Integration with password manager (?). See open issues.

6. User experience design

Outline password field in red. Add text boxes with more input leveraging HTML 5 Constraint Validation. Possibly use a placeholder for the password field like "insecure".

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=* What do we mean by "Highlight"?

    • icon in the placeholder for all type=password (ex: lock and unlock)
    • 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
    • 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.
  • 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?
  • If an https page has a form submit target that call is 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 may already be handled with a Security Warning alert box. See people.mozilla.com/~tvyas/https_post_http.png and people.mozilla.com/~tvyas/https_post_http_with_js.png
    • 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?

|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 |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.
  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.
  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.
  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 people.mozilla.com/~tvyas/https_post_http.png and people.mozilla.com/~tvyas/https_post_http_with_js.png

|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 unecrypted password may be accessible by eavesdroppers/attackers. Note that websites with non-ssl display-only content are an exception. |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 |Feature functional spec=Phase 1: Use cases 1-3 - General case. (Considering adding a phase and including Use Case 3 in Phase 1b.)

Phase 2: Use case 4 & 5 - Deal with mixed content.

Phase 3: Integration with password manager (?). See open issues. |Feature ux design=Outline password field in red. Add text boxes with more input leveraging HTML 5 Constraint Validation. Possibly use a placeholder for the password field like "insecure". |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 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

  • 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

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Features/HighlightCleartextPasswords&oldid=424720"