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

 > 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.

I am really confused by this response. I say when the developer uses a 
type="password" field, we should assume the input is a sensitive 
credential, warn the user (at least) if it's over HTTP, and potentially 
even block password fields from being sent over HTTP. This will "break" 
while I'm working in dev so it should be rare when new apps have this 
data-exposure problem. Sure, this defense may break legacy apps, but it 
*SHOULD* break legacy apps that send passwords over HTTP due to password 
reuse and all the other modern problems with passwords.

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.

With respect,
- Jim



On 12/26/14 11:09 PM, Craig Francis wrote:
> On 26 Dec 2014, at 22:49, Jim Manico <jim.manico@owasp.org 
> <mailto: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 
> <mailto: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 
>>>> <mailto: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 
>> <mailto:security-dev+unsubscribe@chromium.org>.