1345400 - Partial bypass of the "Insecure password" warning in Firefox 52

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[name]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170303012758

Steps to reproduce:

The “This connection is not secure” warning on username and password fields on pages that don’t use HTTPS can be partially "bypass" on the username field by using type="textarea" instead of type="text" in an input field.

The warning will appear only on the password field and not on the username field.


Actual results:

The following tag raises a warning: 
<input id="POST-name" type="text" name="username">

The following tag does not: 
<input id="POST-name" type="textarea" name="username">



Expected results:

The warning should appear too.

Comment 1

[Johann Hofmann [:johannh]]

That's an interesting workaround but I'm not sure we can solve the underlying problem. If a website is really determined to circumvent the insecure password warning (e.g. by filling a hidden form using JS) we can not prevent that and IMO we should not try to. The warning will still catch the vast majority of insecure login forms.

A disadvantage of these tactics would be that you lose the browser autocomplete functionality which many users rely on (and third party password managers will likely not work). So for any website that cares at least a bit about usability the easiest way to "bypass" the warning will still be to upgrade to HTTPS.

There's also the small indicator in the identity block that signals to the user that the site is insecure.

So this is probably a WONTFIX.

Comment 2

[Daniel Veditz [:dveditz]]

We are assuming the site is not actively malicious -- you're trying to give them your password after all! This UI is to help educate users about the risks of insecure connections, and a nudge to site authors NOT to send passwords insecurely. This has been known to be a bad practice as long as Firefox has existed (see this early 2005 IEBlog post, and this was established wisdom even then: https://blogs.msdn.microsoft.com/ie/2005/04/20/tls-and-ssl-in-the-real-world/ )

If a page wants to put in the work to fool users without putting in the work to just get a free certificate we can't stop them. Other techniques (that we have seen!) include using two text fields and using javascript to make the fake password field look like ******.