Live data from Hacker News

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

security.googleblog.com

291–300 of 419 posts

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

#291

Earlier quoted context omitted.

How happy will your customers be when they find out that you're just pulling the wool over their eyes instead of doing your job?

Did you read what I wrote? I do my job but there's only so much I can do if the owners of the servers who are serving my software tell me "before we can change this server's configuration we need approval from another office, it will be a few months until they can get back to us." (This is a hypothetical situation, for me, because I eventually got all my customers on HTTPS back around 2012 or so. There was some push…

Man, that fourth paragraph is a work of art.

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

#292

Earlier quoted context omitted.

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…

As someone who runs like a roleplaying site for like ten people (or several of them), I cannot be responsible for other people's bank passwords, nor should I be punished for daring to host websites without the huge added burden of cost of HTTPS. The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.

Then really, Google's done you a solid. Now everyone using your site will know it's not as secure as their bank, and therefore, when their creds for your sites are stolen, and they get their identity stolen as a result, you can just say "Hey, everything told you it wasn't secure, not my problem"...

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

#293
post #192
post #24

What should be done for routers and printers that are accessed by their IP address?

I suppose it really depends on your threat model. I think most offices will be fine with the warning. However, you could configure each device to only respond to the trusted IP address of a HTTPS proxy which at least lowers the attack surface for snooping.

wait, wait, wait, are you saying a "trusted ip address" out on the web? or requiring every office to set up their own https proxy? Cause a "trusted IP address" out on the web would just be insane... "Oh, let's just send my login to and give full access to my network to this third party/manufacturer."

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

#294

Earlier quoted context omitted.

https://certbot.eff.org/ This. This this this. Automates everything so easily. I have helped someone personally deploy HTTPS for over a dozen sites and they all auto-renew without a hitch every 90 days. No Excuses. EFF did us a solid

Except the part where if you're using shared hosting and don't have the ability to run this software on your server, it's useless as I said.

One might also conclude that the hosting provider is useless.

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

#295

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…

> Same with Go.

Out of curiosity, what are you referring to? Go has great HTTP/2 support, and is enabled by default since 1.6. It doesn't depend on OpenSSL either, which is a big bonus in my book

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

#296
post #151

Earlier quoted context omitted.

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 L…

Correct. The rate limits for the parent domain wouldn't apply if it was added to the public suffix list. The IP restriction wouldn't apply because every router would be requesting from a different IP.

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

#297
post #239

Earlier quoted context omitted.

Security follows a weakest link approach. With your aquarium enthusiasts forum that weakest link would be shared passwords between that forum and other, more important sites.

Shower Thought: Why doesn't the browser hash the inputs for all password fields, then compare them when attempting to submit a form, and alert the user that they are doing something insecure?

Besides issues like requiring javascript or something, its usually not a useful step. The hash of the password can be stolen just as easily as the password itself. You've just made a new password.

If you salt the password with the url, all you've done is made a unique password per website which is what you were supposed to be doing anyway.

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

#298
post #218

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?

Until users stop using the same password everywhere, your aquarium website is effectively the security for all your users accounts, including their bank.

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

#299
post #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.

In addition to all the genuine "let's make the web better" reasons, comprehensive TLS prevents middleboxes from inspecting or tampering with traffic, which in turn allows the introduction of better protocols like SPDY and HTTP/2, which brings content to users faster and allows pages that contain more disparate/modular content, which makes web applications more capable (in addition to the added security), which makes it easier and more appealing to migrate away from locked-in platforms. (And that's just one of many lines of reasoning.)

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

#300

Earlier quoted context omitted.

I am not a security expert, but as I understand it, passwords sent in the clear are vulnerable to being intercepted. Even if users of your site don't have much to worry about from those accounts being compromised (this may or may not be true), lots of people use the same password for more than one login, so their accounts on other sites could be compromised too. That's definitely a significant security risk, even if…

I know I guess I just have to vent some frustration. Time to move on I guess. Does anyone have good hosting suggestions for a web app that has a 1GB database and a few thousand active users? I can only afford ~10-20 EUR a month on shared hosting atm.

> I can only afford ~10-20 EUR a month on shared hosting atm.

Sounds to me like you can move to a better host that does provide LetsEncrypt and save money on your hosting costs to boot!

Post reply on HN