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.
Chrome 56 will mark HTTP pages with password fields as non-secure
251–260 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#252Earlier 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.
All you'll see without it is broadcast crap.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#253Earlier 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.
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
#254I'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…
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
#255It 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
#256Earlier 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?
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#257Earlier 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?
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
#258Earlier 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…
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
#259Earlier 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?
(Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#260Get that HTTPS motor running. This really does make it easy.