Live data from Hacker News

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

security.googleblog.com

231–240 of 419 posts

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

#231

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.

Bullshit. Not if you have shared hosting. Or 1000 over different situations that you clearly have not thought about.

So shared hosts will have to move to making HTTPS simple to implement for their users. Sorry, but progress must be made in this area.

And if not, it's no big deal, users will just be informed that the page is not secure, which is true.

Don't like the message? Work to secure your damn website.

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

#232

Earlier quoted context omitted.

With free ways to encrypt web coming out, you really have no excuse to not use https for login forms. People should be informed.

This is not the right way to educate people. This is a sort of like shaming someone in to doing something. Many small companies are going have an impact thanks to this. There are many companies I have personally witnessed that use a direct IP to access web based solutions to their inhouse software, how are these people supposed to get a ssl cert. We need to educate people, not shame them in to doing the things big go…

A web developer or website manager has a responsibility to be informed. SSL/TLS is not a new development, it's been around for 20 years, and recommended for login forms for at least a decade. At this point, what exactly should they do? Send people to knock on the doors of every business with a site?

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

#233

Earlier quoted context omitted.

The majority of the big sites that people use (Google, GMail, Youtube, Facebook, Reddit, NYT, WaPo, etc.) are already being served using HTTPS. I think if a couple of HTTP sites an average user still browses start showing these warnings they will notice them. And what matters, the owners of those websites will notice them and will ask their "IT guy" hey "why our website is marked as insecure? I want a green lock like…

Their IT guy?? There are gazillions of people like me who have a blog, or some small project that has a small audience of tens to just a few thousand users. All these people now have to fork for SSL, or have to move everything to a different shared hosting that supports Let's Encrypt.

Your shared hosting service doesn't need to support Let's Encrypt, it just needs to allow you to upload a certificate. You can use https://gethttpsforfree.com/ to generate it.

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

#234

Earlier quoted context omitted.

Because, here in the real world, my paycheck depends on keeping my customers happy.

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 back and it did take a long time and we had to be very persistent with some customers... But it was well worth it!)

We are talking about the world of corporate IT and pointy haired bosses. I don't implement a social network, or email, I don't accept payments - I make intraweb sites that non-technical corporate paperpushers use to do their job. They are only interested in getting their work done; they are happy when they can get their work done without scary warnings they don't understand. If my software is giving them errors they are going to believe that it's my software that's the problem, and that doesn't look good for us. And we have to field support calls and explain ourselves.

...Or we could put a quick and dirty stopgate in to avoid something that makes us look bad and we can't do anything about.

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

#235

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.

LDHosting's shared hosting costs me 35€/year, gives 5GB of disk space and lets me upload my own cert for free. I've been with them for a few years and the uptime has been excellent.

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

#236

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…

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.

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

#237

Earlier quoted context omitted.

I'd be in favor of banning input manipulation but adding custom fields like phone which would accept regex formatters.

Browsers already support that. Good look convincing managers/clients/designers that they're sufficient on their own though. The real problem is UI. Most of these plugins are changing the UI of forms to something that looks fancier (and more consistent) than the defaults.

There really does need to be a better way to style inputs. It's all over the place now. Hell, just making `type=search` look the same across browsers isn't as straight forward as it should be.

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

#238

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.

It may take way more than 5 minutes. My experience with let's encrypt so far: - the name of their tool was changed form "letsencrypt" to "certbot", breaking my cronjob - for daemons that try to access the cert/key as non-privileged users, additional fiddling with permissions is necessary, which may even be overwritten on cert update if done incorrectly - when the certs are renewed, daemons need to reload them. This m…

> I, for one, opted to renew my startcom certificate for another 3 years instead.

Wait really? When did you do this? I thought all certs signed by their root after sometime in October or November are all considered invalid due to their shenanigans with WoSign. Not so?

https://news.ycombinator.com/item?id=12787029

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

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

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.

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

#240
post #4

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

Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today? Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" Now all my users are going to hear that my site is insecure, when nothing at all changed. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard…

>Now all my users are going to hear that my site is insecure, when nothing at all changed.

Nothing's changed: Your site really is insecure, it's just that now users know.

Post reply on HN