> On 26 Dec 2014, at 22:49, Jim Manico <jim.manico@owasp.org> wrote: > > Submitting a password over HTTP. I mean, this is a really LOW bar to win. May I suggest a few phases? The problem is that the browser does not know what the data really is... it's only because the input has its type set to password that it can even guess that it might be a password... it's trivial to not mark it as such. But then again, should we really be using passwords? They have been proven many times to be broken... i.e. re-use of the same value every time you attempt to login, so once known it can be used time and time again (which is why your credit card identifier/number is really not good enough to protect your money)... but that is a discussion for another day, ideally when we have viable alternatives :-) Craig > On 26 Dec 2014, at 22:49, Jim Manico <jim.manico@owasp.org> wrote: > > Submitting a password over HTTP. I mean, this is a really LOW bar to win. May I suggest a few phases? > > Phase 1 = warn the user when they are about to submit a password field over HTTP (do some browsers do this already?) > Phase 2 = submit a recommendation and guidance to have development tools warn the developers somehow during development... > Phase 3 = ban this practice in the browser someday > > On 12/26/14 12:38 PM, Craig Francis wrote: >>> On 26 Dec 2014, at 22:20, Jiri Danek <softwaredevjirka@gmail.com> wrote: >>> >>> Have there been any suggestions what to do about <FORM>s sent over HTTP that include <INPUT type="password">? For example marking the password field itself as dubious/insecure? (I am absolutely not saying that is what browsers should be doing, mind you) >> >> Oh, just set the form action to an invalid HTTPS url, and change it with JS on the submit event, or just send via AJAX... see perfectly secure (no warnings), you can even use rot-13 for extra protection... and who cares about non JS browsers? :-P >> >> Seriously though, we need to start moving over to HTTPS only... baby steps at first (e.g. tiny UI hints to educate users), fix the issues (e.g. issuing and installing certs), but we can get there eventually :-) >> >> Craig > > To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.
Received on Saturday, 27 December 2014 09:09:43 UTC