MozillaWiki

Security/Features/HighlightCleartextPasswords: Difference between revisions

Page Discussion

Security/Features/HighlightCleartextPasswords (view source)

Revision as of 19:07, 22 November 2013

43 bytes added ,  22 November 2013
no edit summary
No edit summary
No edit summary
 
(18 intermediate revisions by 2 users not shown)
Line 5: Line 5:
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Lucas Adamski
|Feature product manager=Sid Stamm
|Feature feature manager=Tanvi Vyas
|Feature lead engineer=Tanvi Vyas
|Feature lead engineer=Tanvi Vyas
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature open issues and risks=Current/Latest Proposal:
|Feature open issues and risks=<b>Current/Latest Proposal:</b>
* 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).   
* See presentation: https://wiki.mozilla.org/images/5/5a/HighlightPasswordsPresentation.odp
* When the user clicks on the warning icon (or any part of the input box?), a doorhanger pops up with text that says something like, "This will submit your password unencrypted/This is an unencrypted page."  If we can determine the ssl version of the page, also include something like, "Click here to go to the encrypted version of this page."   
* 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).  ([http://people.mozilla.com/~tvyas/Warning_Icon.jpg Example Icon])
* If the user mouses over the password input box (as opposed to click on the icon), they will also get a similar message in a Tooltip OR a constraint validation box.  This will overwrite any tooltips/custom validation the website may have set.
* 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. 
* 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)
** 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:
* What do we mean by "[http://dictionary.reference.com/browse/highlight?s=t Highlight]"?
** On focus of password field, icon in the placeholder for all type=password input fields.  [http://people.mozilla.com/~tvyas/redminus.jpg 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
** 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.


<b>Open Issues:</b>
* Should their be positive and negative assertions for type = password fields(ex: sad face and happy face) or only negative assertions?
* 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.
** 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.
Line 38: Line 34:
** Link in the constraint validation hint
** Link in the constraint validation hint


* How do we detect the fqdn of the https version of an http page?
* 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
** Try just adding an s and check the status code in the response
** Leverage data in password manager
** 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.
** 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?
* 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 usernmae/password pairs stored for a site, the password isn't filled in until the user selects the username)
** 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?
** Should we set autocomplete=off for username and passwords?
* 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 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 [http://people.mozilla.com/~tvyas/https_post_http.png here] and [http://people.mozilla.com/~tvyas/https_post_http_with_js.png 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?
|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 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.
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.
|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.'''
#* '''Highlight that the password field is insecure. Provide an option to visit the https version of the page if possible.'''
# A user is asked to login on an https page.  The login form submits to an http destination.  Users password is sent in cleartext.
# 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.'''
#* '''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.
#* Note that if the user hits submit in this case, the user will also get a Security Warning alert box.
# 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.
# 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.'''
#* '''Highlight that the password field is insecure.  Provide an option to visit the https version of the page if possible.'''
# 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.
# 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.'''
#* '''Highlight that the password field is insecure.  Provide the user an option to reload the page with mixed content blocked.'''
# 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).
# 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'''
#* '''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.
# 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.
Line 73: Line 63:
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:
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 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 [http://people.mozilla.com/~tvyas/https_post_http_with_js.png here]).   
* 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 [http://people.mozilla.com/~tvyas/https_post_http_with_js.png 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 the "highlighted" content.  (Example: if an insecure password field has an placeholder, our placeholder would overwrite the existing placeholder).
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:  
|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
https://wiki.mozilla.org/Security/Features/Identify_which_bits_are_unencrypted
Line 82: Line 73:
|Feature functional spec=Phase 1: Use cases 1-3 - General case.
|Feature functional spec=Phase 1: Use cases 1-3 - General case.


Phase 2: Use case 4 & 5 - Deal with mixed content.
Phase 2: Use case 4 - Mixed Script Content.  Blocked on bug 62178.
|Feature ux design=Multiple options here.  See Open Issues - "What do we mean by Highlight."
|Feature ux design=Multiple options here.  See Open Issues.
|Feature implementation plan=https://bugzilla.mozilla.org/show_bug.cgi?id=748193
|Feature implementation plan=https://bugzilla.mozilla.org/show_bug.cgi?id=748193


Line 90: Line 81:
Phase 1: Use cases 1-3 - General case.
Phase 1: Use cases 1-3 - General case.


Phase 2: Use case 4 & 5 - Deal with mixed content.
Phase 2: Use case 4 - Mixed Script Content.
}}
}}
{{FeatureInfo
{{FeatureInfo
|Feature priority=P1
|Feature priority=P2
|Feature theme=Security Leadership
|Feature theme=Security Leadership
|Feature roadmap=Security
|Feature roadmap=Security
Line 115: Line 106:


Other Ideas:
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.
* 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.
* 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.
** 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.
* 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).
* 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
* 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 [http://people.mozilla.com/~tvyas/https_post_http.png here] and [http://people.mozilla.com/~tvyas/https_post_http_with_js.png 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?
Sidstamm
canmove, Confirmed users
1,537

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/430776...768577"