Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

security.googleblog.com

Post reply on HN
Print view View original

71–80 of 419 posts

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

#71

Post by kevin_thibedeau »

Moru wrote: post #68
dheera wrote: post #47

Earlier quoted context omitted.

A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate…

But what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?

Why would such a form need a password field?

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

#75

Post by tyingq »

pjc50 wrote: post #66
polygot wrote: post #41

I hope they do this for CC numbers too, because I know of a website I had to use that passed your Name, address, CC number, CC exp, amount; the whole shebang over plain ol' http to do a payment shudder .

I'm fairly sure that violates PCI-DSS.

I suspect PCI is okay with it so long as it is an unsecure page that posts to a secure one. Not that it's a great idea, but it would be encrypted in transit.

Edit: It appears PCI DSS V3.2 does ask that the form itself be on a secure page (section 4.1.g):

"for browser-based implementations: 'HTTPS' appears as the browser Universal Record Locator (URL) protocol, and Cardholder data is only requested if “HTTPS” appears as part of the URL."

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

#76

Post by Moru »

kevin_thibedeau wrote: post #71
Moru wrote: post #68

Earlier quoted context omitted.

But what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?

Why would such a form need a password field?

Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections...

There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.

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

#77

Post by phire »

clairity wrote: post #32
vortico wrote: post #19

Earlier quoted context omitted.

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.

google competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free? sorry to say, but https is not an altruistic move by google.

And since a large majority of websites import either google analytics or google words, google gets all the infomation for https websites anyway.

I'm willing to bet that the terms and conditions for both services allow google to reuse use the analytics infomation.

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

#78

Post by hackinthebochs »

polygot wrote: post #41

I hope they do this for CC numbers too, because I know of a website I had to use that passed your Name, address, CC number, CC exp, amount; the whole shebang over plain ol' http to do a payment shudder .

Honest question, who is in a position to tap your connection such that this becomes a serious security concern? IT staff at your company? The admins at your ISP? The NSA? I'm assuming that public wifi has session-specific encryption keys. I don't see these as the kinds of concerns that would warrant the kind of panic that some people seem to show over HTTP.

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

#79

Post by nkkollaw »

dheera wrote: post #47
bsimpson wrote: 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…

A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate…

Honestly, why would you do any of those things, now that installing a certificate takes 5 minutes and is free, with Let's Encrypt?

I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.

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

#80

Post by PretzelFisch »

bsimpson wrote: post #5
foota wrote: 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…

you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low...
Post reply on HN