I'd go a leap further and change the background color of the address bar to red if it's a non-HTTPS page. No excuse for any site to be HTTP in 2017, especially with LetsEncrypt. Your host doesn't allow LetsEncrypt? They need to get with the times, or you need to switch hosts. (Why would you want to use a host that doesn't see the value of HTTPS?)
Chrome 56 will mark HTTP pages with password fields as non-secure
381–390 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#382Earlier quoted context omitted.
Yes. Every website. Because if only the sensitive sites are strongly encrypted, then bad actors and authorities know exactly where to focus their efforts in trying to steal information. When everyone is strongly encrypted, attackers are stretched much more thinly. Besides, it's easy and free these days. Unless, apparently, you use some crappy shared hosting provider. Get a VPS, man! They're cheap!
Wouldn't putting someone (whose server experience level warrants shared hosting) in charge of a VPS create more security issues?
Linux is fairly secure by default, so most of what that admin has to do is just not screw it up. Turn off SSH passwords and disable root login, then read a hardening guide for their particular tech stack. Once it's set up, you just need to log in once in a while to update software.
Also backups, if it needed to be said.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#383I'd go a leap further and change the background color of the address bar to red if it's a non-HTTPS page. No excuse for any site to be HTTP in 2017, especially with LetsEncrypt. Your host doesn't allow LetsEncrypt? They need to get with the times, or you need to switch hosts. (Why would you want to use a host that doesn't see the value of HTTPS?)
As stated in the article, that is in fact the long term goal for treatment of the Google Chrome address bar.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#384Earlier quoted context omitted.
Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. I was setting up a WP blog for a family member the other day and saw the option and it was super easy. I've added to my backlog to go turn it on for all my other sites as soon as I've confirmed it won't break anything (ie. loading assets using absolute urls that use http. B…
> Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. How do they do this? How do you set up an SSL cert on a shared host (aren't SSL certs tied to an IP)? I have a site on a virtual host (via Hurricane Electric), and I don't want to move to another hosting provide (cloud hosting) if I can avoid it. But unless something has…
This is no longer the case: http://webmasters.stackexchange.com/a/13990 You can have multiple sites on the same IP all have their own TLS cert.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#385Earlier quoted context omitted.
> Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. How do they do this? How do you set up an SSL cert on a shared host (aren't SSL certs tied to an IP)? I have a site on a virtual host (via Hurricane Electric), and I don't want to move to another hosting provide (cloud hosting) if I can avoid it. But unless something has…
This is no longer the case: http://webmasters.stackexchange.com/a/13990 You can have multiple sites on the same IP all have their own TLS cert.
After I posted I did some research and saw that, but thanks for posting the clarifying link.
I also found that my hosting provider (HE) does have something where on vhosts they have an SSL side - but as far as I can see they don't support (that is, by default or whatnot) Let's Encrypt certs.
However, digging deeper - there may be a way for me to set it up; I'd need to use a different LE client that doesn't need root access (there are a few), then I'd also have to set up a cron task to renew the cert every (I might still fire an email over the HE - maybe it's finally time for me to move away from them and over to Digital Ocean or something that supports LE certs out-of-the-box (I'd still have to fix the links on my site - but then again I've thought about just revamping my site again - it's due for it)...
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#386Earlier quoted context omitted.
I'm not sure that really fit what is changing here... If the forum is submitted it's going over https even if the iframe is on an http page. If an attacker has the ability to add code (iframe or other) to your site you've already lost.
that's exactly my point. I am hoping/assuming chrome would notify the user about this as well.
Why? IIRC cross-origin will prevent the http page from reaching into the https iframe and furthermore the password is being sent over https so google doesn't really care.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#387Firefox has started to do this recently and it's been fantastically informative and helpful. It's the one new browser feature I never really considered wanting/needing before, that's really stood out to me as being incredibly valuable since I've started to see the warnings pop up.
Firefox has started to do this recently "Note that is warning in the url bar is only in Firefox Nightly and Firefox Developer Edition. This has not been released to Firefox Beta and Firefox Release."[0] So this is not a security feature that most end users can rely on, yet. [0] - https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...
Firefox Release channel has been logging console errors for this for at least two years.
"Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen."
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#388Earlier 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?
Sounds kind of rube-goldberg-y compared to automatically generating and managing a unique password for every site.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#389Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"
Well I'm fairly certain it will go like this for me. Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure" Developer - "But you didn't care when there was no encryption" Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".
Developer - "FIPS-140 has been compromised by the NSA. We don't want government spies in our servers."
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#390Earlier 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…
I've never said SSL isn't important nor that I don't care about it. My beef is how Google forces this change on everyone, but at the same time haven't the balls to shake things up and make SSL easily available for everyone. Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. THAT is lame on Google…
> But I guess this is the transition now that is going to be painful for lots of small sites / apps like me. I genuinely never heard this a year ago so they shoudl also have made a big announcement of this much sooner to give time to small guys like me to prepare.
Pretty sure they did. Sorry, but if you're going to be the one responsible for keeping a website online, you have at least some responsibility to keep an eye on tech news just to see if there are any major security breaches or changes in how the web will work coming up. If you don't have time to do this, you really ought to take the site down and move the functionality to some other type of hosting where somebody else takes care of this for you. Otherwise, you may find your site hacked and running a spam server or serving kiddie porn or something one day.