Live data from Hacker News

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

security.googleblog.com

251–260 of 419 posts

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

#251
post #204

Earlier quoted context omitted.

It doesn't matter what the password is protecting on any particular site. Password reuse is common enough -- who knows what else the user is protecting with that password.

This is actually a good example. The password clearly isn't protecting anything. It's a tutorial on how to make a password field! Nobody is going to put a valuable password in there.

And now they'll have an extra reminder not to enter a real password in an example field. Seems good to me.

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

#252

Earlier quoted context omitted.

If I have two devices connected to a switch, how can they see each other's traffic?

Just download Wireshark and you'll have an easy to use tool that'll show you the traffic.

Not by default, only if you do ARP poisoning, which most consumer switches wont guard against.

All you'll see without it is broadcast crap.

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

#253
post #239
post #218

Earlier quoted context omitted.

"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?

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?

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

#254

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

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

I keep hearing this, but failing to see it. Since OpenSSL's inception.

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

#255
There should be an HTTP Header (or a CSP directive) to allow servers to set sites as "Not Secure" manually. That would help a lot of people dealing with phishing attacks on web hosts.

It would function in the same way - if Chrome detects CC/password forms, it labels the site as Not Secure.

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

#256
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?

Probably not a bad idea. But at that point you're fighting human nature.

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

#257

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…

> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?

This is such a weird argument to have when incentivizing w3schools to use SSL would be a good thing. They can clearly afford the cost of acquiring, installing, and maintaining an SSL certificate. And as a website that teaches people about the web, they should be setting an example by using SSL. Alternatively, they should be setting an example by demonstrating that password prompts that aren't over SSL will cause warnings.

But even if it were legitimate for w3schools to not use SSL, security is about tradeoffs, and the tradeoff is that it's absolutely worth displaying a warning on one page that arguably doesn't need instead of not displaying it on millions of pages that definitely do.

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

#258

Earlier quoted context omitted.

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.

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://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

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

#259
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?

Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay.

(Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)

Post reply on HN