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

On 3 Jan 2015, at 08:15, Jim Manico <jim.manico@owasp.org> wrote:
> 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.




Hi Jim,

I really share your frustration, and going back to the original proposal (Marking HTTP As Non-Secure), I believe that is a better solution than alerting users about forms submitting passwords over HTTP.

Keeping in mind that many websites that have implemented HTTPS still use HTTP to load the form, hope that the form still submits to the correct HTTPS url, sets a (non-secure) cookie, and redirects back to the HTTP website... because "HTTP is faster":

https://istlsfastyet.com/

It's also why the HTTP shaming blog is constantly posting examples of this very problem (and not that many websites fix the issues afterwards):

http://httpshaming.tumblr.com/

I wish I can be as optimistic as you about the culture for developers and general security improvements... unfortunately nearly every website developer I have talked to (at quite a few conferences) have little to no knowledge about the security features available to them... they generally want to get the job done, and leave the office by 5:30pm.

It's one of the reasons I'm really pushing for a security tab in the web dev tools, to help with education and usage of the features that are available... i.e. have you tried implementing a CSP header before? it's good fun :-)

https://github.com/craigfrancis/dev-security

Craig





On 3 Jan 2015, at 08:15, Jim Manico <jim.manico@owasp.org> wrote:

> Craig,
> 
> 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 crime. 
> 
> - Jim
> 
> 
> On 1/2/15 9:55 PM, Craig Francis wrote:
>> 
>> On 2 Jan 2015, at 22:09, Jim Manico <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
>