Live data from Hacker News

Chrome 56 will mark HTTP pages with password fields as non-secure

security.googleblog.com

11–20 of 419 posts

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#11
post #5
post #3

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Loo…

> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways.

For anyone who is wondering what these ways are, here are a couple:

1) Backspace is a crufty special case

2) What happens when someone highlights text in the input box and types over it?

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#14
post #12

It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.

"Studies show [...] that users become blind to warnings that occur too frequently."

So right now it would be counterproductive to mark all http pages as "not secure". But it's the long-term goal.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#15
post #12

It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.

That will happen eventually; both Firefox and Chrome have already taken some steps in that direction. But it has to happen as a gradual transition, with plenty of time for people to switch to HTTPS in response.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#16
post #5

Earlier quoted context omitted.

Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Loo…

That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable. Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.

My previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#17
post #5
post #3

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Loo…

> onKeyDown

Right-click paste from my password manager, and it doesn't work. Thanks.

---

This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#18
post #12

It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.

^ 100% agree. I think just marking HTTP pages with password fields as Not Secure would make HTTP pages without passwords fields appear to be secure. This is obviously not the case---they are just as insecure because you are sending your session cookie which is equivalent to your password---so all pages should be marked Not Secure.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#19
post #7

Advancing HTTPS is one of a few good things Google made in the recent years. Thanks Google.

It's one of the few things they do that I can't find a reason they would be financially motivated to do so, other than increase developers' opinions about the company as a whole, which is a good thing for all.
Post reply on HN