Security/Features/HighlightCleartextPasswords: Difference between revisions

← Older edit

Security/Features/HighlightCleartextPasswords (view source)

Revision as of 19:07, 22 November 2013

10,246 bytes added , 22 November 2013

no edit summary

Sidstamm

canmove, Confirmed users

1,537

edits

@@ Line 5: / Line 5: @@
 }}
 {{FeatureTeam
-|Feature product manager=Lucas Adamski
+|Feature product manager=Sid Stamm
+|Feature feature manager=Tanvi Vyas
 |Feature lead engineer=Tanvi Vyas
 }}
 {{FeaturePageBody
-|Feature overview=Highlight passwords and other sensitive data that is not transmitted over ssl.  We will focus on type=password.
+|Feature open issues and risks=<b>Current/Latest Proposal:</b>
-|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.
+* See presentation: https://wiki.mozilla.org/images/5/5a/HighlightPasswordsPresentation.odp
-* A user is asked to login on an https page.  The login form submits to an http destination.  Users password is sent in cleartext.
+* 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])
-* 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.
+* 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.
-|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)
+** 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).
+<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?
+** 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: [http://people.mozilla.com/~tvyas/greenplus.jpg Green Plus] and [http://people.mozilla.com/~tvyas/redminus.jpg 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 [http://people.mozilla.com/~tvyas/inconsistent_positive_assertion.jpg 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.
+#* '''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.
+#* '''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.
+# 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.'''
+# 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.'''
+# 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'''
+# 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 [http://people.mozilla.com/~tvyas/https_post_http.png here]and [http://people.mozilla.com/~tvyas/https_post_http_with_js.png here]
+|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 [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 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.
 }}
 {{FeatureInfo
-|Feature priority=P1
+|Feature priority=P2
+|Feature theme=Security Leadership
 |Feature roadmap=Security
 |Feature engineering team=Security
 }}
 {{FeatureTeamStatus}}
+== Additional Notes ==
+https page with http form post:
+* chromes behavior:  does nothing.
+* safari: warning text
+**"This is a non-secure form.<br/> 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.<br/> 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 [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?