Security/Features/HighlightCleartextPasswords: Difference between revisions

Security/Features/HighlightCleartextPasswords (view source)

Revision as of 23:29, 14 May 2012

1,455 bytes added , 14 May 2012

no edit summary

Tanvi

canmove, Confirmed users

285

edits

@@ Line 9: / Line 9: @@
 }}
 {{FeaturePageBody
-|Feature open issues and risks=* What do we mean by "[http://dictionary.reference.com/browse/highlight?s=t Highlight]"?
+|Feature open issues and risks=Current/Latest Proposal:
+* 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).
+* 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."
+* 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.
+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.
@@ Line 21: / Line 28: @@
 ** 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
@@ Line 33: / Line 41: @@
 ** 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.
 * 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?
@@ Line 40: / Line 47: @@
 * 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?
+* 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
@@ Line 109: / Line 116: @@
 * 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.
 * 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).