Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

security.googleblog.com

Post reply on HN
Print view View original

301–310 of 419 posts

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

#301

Post by icebraining »

mappu wrote: post #282
icebraining wrote: post #215

Earlier quoted context omitted.

So don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.

Our application is still maintained, so we can find workarounds or restructure the form to use an extra popup (to the detriment of usability). But i'm sure many applications won't be updated, and as a result of this change, data will be silently corrupted when they are used. The browser has knowingly broken compatibility with the web application. This is a Torvalds "don't break userspace" moment.

Fair enough, that's a valid concern. But it wouldn't be solved by allowing pages to opt-out of autofill, since they'd have to be updated to use those as well.

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

#302

Post by ocdtrekkie »

protomikron wrote: post #294
ocdtrekkie wrote: post #270

Earlier quoted context omitted.

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.

Or the expectation that everyone take a huge cost burden to appease El Goog is a bigger burden than the startup industry realizes. There's really no solution for HTTPS that does less than double my hosting costs, either I have to buy expensive certs or move to another hosting provider which would support Let's Encrypt. Either way it's a couple hundred dollars a year to maintain hobby sites, which don't pay for themselves to begin with.

Of course, it works in Google's favor to make it unfeasible to maintain a website outside a cloud platform. It's amazing here people are so opposed to the democratization of the Internet, and so supportive of the death of it, over security provisions that will, in retrospect, be considered largely ineffective.

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

#304

Post by sametmax »

onion2k wrote: post #298
Yver wrote: 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?

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

+1. So much +1.

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

#305

Post by sametmax »

johndoe4589 wrote: post #95
lucideer wrote: 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…

Your site IS INSECURE. Nothing at all changed because it was, and now the user can just see it.

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

#306

Post by a_imho »

onion2k wrote: post #298
Yver wrote: 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?

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

How is that the websites fault?

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

#307

Post by onion2k »

a_imho wrote: post #306
onion2k wrote: post #298

Earlier quoted context omitted.

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

How is that the websites fault?

It isn't the website's fault that users do things wrong. It's the users' fault. However, it is the website developer's job to mitigate obvious problems. We know that users do things that are stupid so we have to work a little harder. We have to build products that recognise what the basic minimum standard is, and then try exceed it. If you're transferring passwords across the internet in plaintext then you haven't managed to do that and you need to try harder.

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

#308

Post by disiplus »

michaelmior wrote: post #101
nkkollaw wrote: post #79

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.

> takes 5 minutes This is entirely dependent on how your site is hosted. For some shared hosting platforms, it may not be possible at all.

also u have to do the request over port 443, and the alternative dns validation is not supported in in the official client. so its 5 min only in ideal case.

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

#309

Post by sofaofthedamned »

ocdtrekkie wrote: post #270
no_wizard wrote: post #258

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.

Then use one of the offline challenges.

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

#310

Post by nkkollaw »

barnacs wrote: post #193
nkkollaw wrote: post #79

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 just followed the instructions on their website, and it took me less than 5 minutes, including setting up the cronjob.

The cronjob correctly renewed the certificate at least once on multiple servers, with no issues whatsoever. I was also warned that the certificates were expiring via email, which I thought was awesome.

Your mileage might vary.

Post reply on HN