Security/Features/HighlightCleartextPasswords: Difference between revisions

Security/Features/HighlightCleartextPasswords (view source)

Revision as of 22:20, 17 April 2012

1,984 bytes added , 17 April 2012

no edit summary

Tanvi

canmove, Confirmed users

285

edits

@@ Line 9: / Line 9: @@
 }}
 {{FeaturePageBody
+|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?
 |Feature overview=Highlight passwords and other sensitive data that is not transmitted over ssl.  We will focus on type=password.
-|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.
-* 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.'''
-* 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 https 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 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'''
+#* Open Issue - how do we tackle this scenario?
 |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
+Phase 2: Use case 4
+Phase 3: Determine what to do about Use Cases 6.  Open Issue.
+|Feature ux design=Outline username and password field in red.  Add text boxes with more input leveraging HTML 5 Constraint Validation.
 }}
 {{FeatureInfo