Open Bug 947471 Opened 11 years ago Updated 2 years ago

Notify users when password fields are present on http documents, or when they'll be submitted via http

Categories

(Firefox :: Security, defect)

defect

Tracking

()

People

(Reporter: ialagenchev, Unassigned)

References

Details

Support has been added to the browser to detect insecure password fields and notify developers when they occur: https://bugzilla.mozilla.org/show_bug.cgi?id=762593 and work is currently being done to notify different components, including add-ons when such fields are detected: https://bugzilla.mozilla.org/show_bug.cgi?id=899983
The community has expressed interest in such feature: https://bugzilla.mozilla.org/show_bug.cgi?id=762593#c90, https://twitter.com/passy/status/390790063451152384/ and at least one developer is already working on providing notifications to users: https://github.com/alagenchev/ArktikFoxAddOn

We should make changes to the Firefox UI to notify users about this vulnerability. 
Probably the most challenging part of this work is coming up with an effective UI element.
This is an important security issue and I'm voting to have it implemented as soon as possible. Tools such as sslstrip[1] have existed for several years now, and we don't have an effective way to mitigate such attacks. In addition, web developers lack education about appropriate security measures. This feature will help both.

Warning for insecure password forms will help in the following areas:

 * It will add a layer of complexity to sslstrip-style attacks, as they will not be able to use the native input fields with a password type. In the future, after this feature is implemented, we can communicate to users via the UI whether they are using a legit input field with type=password via positive feedback, something that can be implemented later as an additional feature.
 
 * It will force developers to be more careful about designing secure websites. Currently, absence of negative feedback to the user encourages bad security practices and web developers do not have enough incentive to provide decent security mechanisms. Many websites don't use HTTPS at all and send passwords in the clear, with their form actions being HTTP. Especially smaller websites even send credit card numbers in the clear [4]. Perhaps it should be discussed how to detect such issues using heuristics in addition to passwords sent in the clear, but this is something that pertains to another issue to-be-opened.

 * It will educate developers about the fact that HTTPS is not only about encryption, as most web developers would think, but also about integrity, and that HTTPS must be used to both serve a password form as well as for its submission. For example, sites as big as Slashdot[2], deviantART[3], WordPress[5], and VK[6] have forms served via HTTP and submitted to HTTPS that can be easily hijacked by attackers that have network-level access and can do things like ARP spoofing or DNS spoofing. Javascript injection in these forms is a trivial matter for an active man-in-the-middle attacker, and the attack can be completely transparent to the user.

We are responsible for our users' security. We are responsible for educating developers for best security practices. It is not acceptable to allow developers to use insecure forms for password submission, unless their website receives negative feedback in the browser UI. Given the educational material available online today about these issues, this seems to be the best way to encourage and incentivize developers to fix their issues.

As for the UI, it seems for the moment to be easiest and effective to use the exclamation mark icon that we use for mixed content in HTTPS. While I support the idea that this should eventually yield a big warning to the user which is hard to dismiss and bypass, it is best to slowly transition to such a state and allow developers to fix their issues before we apply bolder measures.

[1] http://www.thoughtcrime.org/software/sslstrip/
[2] http://tech.slashdot.org/
[3] http://www.deviantart.com/
[4] http://www.hayesvalleyinn.com/booking.html
[5] http://wordpress.com/
[6] http://vk.com/
Fantastic comment, Dionysis.  Very well said.  :-)
The UI is the trickiest part here.  This looks like a duplicate of bug https://bugzilla.mozilla.org/show_bug.cgi?id=748193.  Also see this feature page - https://wiki.mozilla.org/Security/HighlightCleartextPasswords.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.