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

241–250 of 419 posts

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

#241

Post by stanleydrew »

ocdtrekkie wrote: post #236
icebraining wrote: post #213

Earlier quoted context omitted.

If there's not sensitive data, then there's no password field (passwords are by definition sensitive), and Chrome won't show a warning. So what's the problem?

Passwords are NOT by definition sensitive, and this is the sort of absolutist nonsense that I'm complaining about. Passwords are only as sensitive as the data they access.

This is false. Passwords are only as sensitive as all the data they access. Given that it's impossible for you to know what other data the user is protecting with the same password, you must assume all passwords are as sensitive as the most sensitive data a user might reasonably secure with that password.

Do I wish things were different, and that everyone on earth used unique passwords for every site? Of course. But I think you know that's never going to describe reality.

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

#242

Post by jaas »

Karunamon wrote: post #153
ocdtrekkie wrote: post #109

Earlier quoted context omitted.

Let's Encrypt is great, but completely useless for... Actually every single website I host. No wildcard certs, the rapid rotation that requires software to renew it regularly, etc. The cost of implementing HTTPS for dozens of sites with no sensitive data is simply not worth it. When companies like Google and Mozilla decided how to handle HTTPS, they decided based on their needs and their perception of everyone else's…

HTTPS is for the user's benefit, not the site owner's (barring legislation, of course). Also, HTTPS prevents hijacking, not just sniffing, of content by a MITM. That includes malware injection. This has been coming for quite a long time. The time for excuses is over. If you think the safety of your users is "simply not worth it", well, I'd like to know what your websites are so I can block them at my firewall. I'm no…

HTTPS is very much for the site owner's benefit as well. If your site is not HTTPS then you can't be sure that your users are seeing what you intend them to see. Ads, malicious script, whatever, can be injected or replace your content.

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

#243

Post by [deleted] »

Karunamon wrote: post #153
ocdtrekkie wrote: post #109

Earlier quoted context omitted.

Let's Encrypt is great, but completely useless for... Actually every single website I host. No wildcard certs, the rapid rotation that requires software to renew it regularly, etc. The cost of implementing HTTPS for dozens of sites with no sensitive data is simply not worth it. When companies like Google and Mozilla decided how to handle HTTPS, they decided based on their needs and their perception of everyone else's…

HTTPS is for the user's benefit, not the site owner's (barring legislation, of course). Also, HTTPS prevents hijacking, not just sniffing, of content by a MITM. That includes malware injection. This has been coming for quite a long time. The time for excuses is over. If you think the safety of your users is "simply not worth it", well, I'd like to know what your websites are so I can block them at my firewall. I'm no…

[deleted]

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

#246

Post by detaro »

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…

> - implement a HTTPS password field in an iframe and communicate with it over post messages.

The top-level page also has to be served over HTTPS for the warning to not appear. (source https://developers.google.com/web/updates/2016/10/avoid-not-...)

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

#247

Post by Wilya »

gregmac wrote: post #230
clamprecht wrote: post #111

What if the submits to an https page but the page is served up on an http page? The form submission will be secure, correct? Will Chrome still mark as insecure?

I was also thinking of the opposite: submitting from an https-loaded page to an http page. I can't imagine why any application would do this (other than by mistake), but it would ideally be flagged as insecure as well.

It's already the case most of the time. If you submit via a plain form (without js), you get the (old) "This page is encrypted, but the information you submitted will be sent unencrypted" message. If you submit via an XMLHttpRequest, it should be blocked as Mixed Content.

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

#248

Post by tialaramex »

caf wrote: post #151
nsgi wrote: post #96

Earlier quoted context omitted.

HTTPS prevents that.

No, because the implication here is that the private key for these router0123.netgear.com type hostnames will be known to the consumer devices that are serving the pages, so they will be essentially public.

I think the idea is each device has its own FQDN, and gets its own certificates. Thus, breaking open your router only gets you "your" private key, they'd all be different. Buying one on eBay might be risky, but if you buy sketchy network hardware on eBay you're at risk in so many ways already...

You can't do this with Let's Encrypt out of the box (unless you make small numbers bespoke devices) because of their Rate Limits. But several commercial public CAs like Comodo would probably be interested in cutting a deal with a big electronics manufacturer or a trade group.

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

#249

Post by msbarnett »

Yver wrote: post #218
twblalock wrote: post #156

Earlier quoted context omitted.

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

"insecure", "huge red flag." For a banking site, an e-commerce site, a webmail, sure. Must an aquarium enthusiast forum be resistant to Man-in-the-Middle attacks? What about weak ciphers? Should every site be resistant to offline decryption by a state actor?

Yes, every site should be. The average user shares their niche acquarium site login username/password with their gmail login and bank and everything else.

In the physical universe we occupy a given user's most security-sensitive site is exactly as vulnerable as their least security-conscious site. It behooves us as professionals to take that fact seriously.

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

#250

Post by stanleydrew »

KirinDave wrote: post #210

I've got to say though, that this is a wee bit frustrating as a developer. SSL libraries are terrible, bug ridden, hard to work with, and there are huge sacrifices using a pass-through proxy to offer SSL. The brittleness of SSL libraries manifests not just in the form of security exploits, but also in the form of delaying the next generation of HTTP technology. Node doesn't support natively support HTTP/2 due to HTTP…

As with most things, progress isn't clean or easy. Shifts in policy or practice cause disruptions, and then people adjust. The world is a dynamic place.

Software is no exception. SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works.

The question is whether the benefit of the disruption outweighs the cost. Browser-makers decided that their users' needs were best served by this change. Mozilla and Google have been telegraphing their actions in this direction for years. They have attempted to make a responsible and gradual transition, and to a large extent have succeeded.

Every once in awhile though, a break needs to be made and some folks will get left behind until they adapt, or don't.

Post reply on HN