- From: ianG <iang@iang.org>
- Date: Sat, 03 Jan 2015 13:44:05 +0000
- To: Jim Manico <jim.manico@owasp.org>, Craig Francis <craig.francis@gmail.com>
- CC: blink-dev <blink-dev@chromium.org>, Jiri Danek <softwaredevjirka@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, "mozilla-dev-security@lists.mozilla.org" <mozilla-dev-security@lists.mozilla.org>
On 3/01/2015 08:15 am, Jim Manico 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. The chance to be bold doesn't come around very often. Now people are thinking about Snowden, this is the best opportunity to make sweeping changes we have seen since forever. Every change results in someone losing something, and that someone decided to take on the jihad to save themselves a little. Every whinge and whine comes at the expense of everyone else. Every excuse places short term, individual issues above the health of the entire ecosystem. The chance to be bold has probably reached its peak. It probably won't get any stronger than today. Don't blink... > 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. In general I agree with HTTPS for all passwords. Only mild comment I'd make is that the whole '****' thing is soooo 1980s. I'm specifically talking about university terminal labs, where students would shoulder surf to steal accounts. These days, people want (need) to see the passwords in clear on the screen because they are so bloody difficult to type because they have to read an 8 hieroglyph masterpiece out of a paper or phone record to keep them secure. Shoulder surfing is the least of people's worries, that they can deal with by ... looking behind them. Security tips become received wisdom become millstones as the threat moves on... iang > 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 > > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security
Received on Saturday, 3 January 2015 13:44:30 UTC