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
- For mixed content pages, how do we differentiate between script content and display content. Is there already a defined variable with this information (or will there be after https://wiki.mozilla.org/Security/Features/Mixed_Content_Blocker and https://bugzilla.mozilla.org/show_bug.cgi?id=62178 are complete)?
- 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? More investigation needed - https://bugzilla.mozilla.org/show_bug.cgi?id=436200
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
- A user is asked to login on an http page. The login form submits to an http destination. Users password is sent in cleartext.
- Outline the password and username field in red.
- A user is asked to login on an https page. The login form submits to an http destination. Users password is sent in cleartext.
- Outline the password and username field in red.
- Note that if the user hits submit in this case, the user will get a Security Warning alert box. More followup needed.
- 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.
- Outline the password and username field in red.
- 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.
- Outline the password and username field in red.
- 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
- 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. 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 type=password, outline the password box in red. Also add a note to the user that occurs onfocus so they know why the form is outlined in red (perhaps utilizing Constraint Validation)
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
Phase 2: Use case 4 & 5 - Deal with mixed content.
6. User experience design
Outline username and password field in red. Add text boxes with more input leveraging HTML 5 Constraint Validation.
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=* For mixed content pages, how do we differentiate between script content and display content. Is there already a defined variable with this information (or will there be after https://wiki.mozilla.org/Security/Features/Mixed_Content_Blocker and https://bugzilla.mozilla.org/show_bug.cgi?id=62178 are complete)?
- 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? More investigation needed - https://bugzilla.mozilla.org/show_bug.cgi?id=436200
|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.
- Outline the password and username field in red.
- A user is asked to login on an https page. The login form submits to an http destination. Users password is sent in cleartext.
- Outline the password and username field in red.
- Note that if the user hits submit in this case, the user will get a Security Warning alert box. More followup needed.
- 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.
- Outline the password and username field in red.
- 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.
- Outline the password and username field in red.
- 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
- 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. 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 type=password, outline the password box in red. Also add a note to the user that occurs onfocus so they know why the form is outlined in red (perhaps utilizing Constraint Validation) |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
Phase 2: Use case 4 & 5 - Deal with mixed content. |Feature ux design=Outline username and password field in red. Add text boxes with more input leveraging HTML 5 Constraint Validation. |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=` }}