W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

From: Jim Manico <jim.manico@owasp.org>
Date: Fri, 02 Jan 2015 22:15:40 -1000
Message-ID: <54A7A52C.2050009@owasp.org>
To: Craig Francis <craig.francis@gmail.com>
CC: Jiri Danek <softwaredevjirka@gmail.com>, "mozilla-dev-security@lists.mozilla.org" <mozilla-dev-security@lists.mozilla.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, blink-dev <blink-dev@chromium.org>

I would agree with the later perspective you are stating 10 maybe 5 
years ago, Craig. But with so many incredibly highly-visible hacking 
incidents in the last few years, /the culture around developers and 
users perspective of security is rapidly changing/. You have a chance to 
be bold at the standard level, possibly even get all of the major 
browsers to agree to said standard, and be a bit more aggressive in 
application security education and awareness in the browser. How much 
can that slider be increased? I'm not sure. But again I really think 
this one, forcing a password field to be transported encrypted, is such 
a low bar in terms of increasing security in the browser.

So when a developer allows a users credential to be sent plaintext, it's 
a huge application security crime. _*If the browser lets this happen 
without any attempt to warn the user or developer, then I call the 
browser a serious accomplice in this terrible and very basic security 
- Jim

On 1/2/15 9:55 PM, Craig Francis wrote:
> On 2 Jan 2015, at 22:09, Jim Manico <jim.manico@owasp.org 
> <mailto:jim.manico@owasp.org>> wrote:
>> So I say the browser absolutely knows that the data is - it's data 
>> that is sent over a field that a developer specifically labeled as a 
>> password. Passwords /*must*/ be sent over HTTPS or nothing in today's 
>> threatscape.
> Hi Jim,
> I really appreciate what you're saying, and I would really like this 
> as well.
> But think about it from the typical programmers point of view... their 
> customers/managers might complain that the password field "looks odd" 
> (the warning approach - where they won't read the error message, 
> that's too difficult)... or does not work at all.
> That developer might implement HTTPS... but in most cases (because 
> they don't have time, or possibly too lazy, with a manager saying 
> "just fix it, and there's no budget for this"), they will just change 
> the input type to "text"... and possibly copy/paste a jQuery plugin 
> that will "bring back the dots", e.g.
> http://www.jqueryscript.net/form/iOS-Like-Plain-Text-Input-of-Password-with-jQuery-mobilePassword-Plugin.html
> http://css-tricks.com/better-password-inputs-iphone-style/
> That's assuming the developer does not say that the browser is broken, 
> and they should use a different one (I've unfortunately seen this 
> response a few times before).
> Craig
Received on Saturday, 3 January 2015 08:16:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC