Live data from Hacker News

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

security.googleblog.com

351–360 of 419 posts

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

#351

Earlier quoted context omitted.

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

where do you work

They seem to be a government contractor.

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

#352

I've been paying rent with www.rentpayment.com which unfortunately serves up their home page with multiple logins over http. Naturally, emails and tweets to their support go ignored. Maybe they'll finally respond after more people ask them why they're "non-secure".

I wrote a short article on this topic with approaches for less tech savvy folks to set up HTTPS:

https://medium.com/punk-rock-dev/https-new-year-avoid-the-no...

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

#353
post #3

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

Pm - "why is this page insecure"

Developer - "chrome labels password fields as insecure over http"

Pm - "what if it wasn't a password field"

Pm - "If its important enough to hide, its important enough to stop from being intercepted. Think social security numbers, PINs, tokens, drivers license numbers, etc. Why aren't we encrypting things that matter?"

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

#354
I'm going to go ahead and make another shameless plug, since a lot of folks who are hesitant about this new HTTPS stack are worried about deployment, and thats for the fantastic folks over at Caddy. They make an Apache/Nginx alternative that has built in letsencrypt renewal support and automatically encrypts your site by default and serves over https/2.

https://caddyserver.com/

I am not an affiliated developer, but I am a user, and have recommended this to others as well, its a solid product.

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

#355

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.

Yeah, but if you want something slighlty different that isn't solved by one of the existing input field types you would be completely out of luck. And even if what you need is in the HTML spec you might be out of luck. Firefox is only adding support for date inputs sometime this year (my estimate) [1].

1: https://wiki.mozilla.org/TPE_DOM/Date_time_input_types#Roadm...

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

#356

Earlier quoted context omitted.

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

What are you talking about? There are plenty of low-cost VPS providers that give you full root access on which you can easily run certbot. That's what I'm doing now, and my hosting provider costs a whopping $20/year.

Say what you will, but pushing for passwords to be transmitted securely isn't Google fighting against the democratization of the Internet. They're doing that in other ways, sure, but promoting encryption isn't one of them.

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

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

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

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

#358

Earlier quoted context omitted.

How cheap? Would you have a suggestion? Thanks.

Low-end dedicated VPS runs around $5/month. See DigitalCloud or Amazon Lightsail. If you want to save a bit more money and are willing to commit to a 1-year contract, you could even get a t2.nano instance from Amazon EC2 at around $3/month.

If you check out deal aggregation sites like LowEndBox you can usually get one even cheaper than that (I pay $20 annually for mine)

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

#359
post #297

Earlier quoted context omitted.

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?

Besides issues like requiring javascript or something, its usually not a useful step. The hash of the password can be stolen just as easily as the password itself. You've just made a new password. If you salt the password with the url, all you've done is made a unique password per website which is what you were supposed to be doing anyway .

The point was for the browser to warn the end user about password re-use.

The browser doesn't need javascript to see the contents of a password field, or to show an indicator in the browser's chrome. It's the browser.

If you salt the password with the url, all you've done is made a unique password per website which is what you were supposed to be doing anyway.

Note that browsers can already store password lists (ex: Chrome settings, search manage passwords). There would just be an extra step to compare those passwords together.

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

#360

Earlier quoted context omitted.

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

What are you talking about? There are plenty of low-cost VPS providers that give you full root access on which you can easily run certbot. That's what I'm doing now, and my hosting provider costs a whopping $20/year. Say what you will, but pushing for passwords to be transmitted securely isn't Google fighting against the democratization of the Internet. They're doing that in other ways, sure, but promoting encryption…

Encryption could be offered without certification authorities that charge huge sums for certs. And there's a link on /new right now about Symantec which continues to reinforce how relying on CAs is a broken concept.

So, right now, I have 24/7 American-based phone support (this is a must-have), 99.9% uptime guarantee, WHM/cPanel software licensing included, 60 GB disk space, 600 GB bandwidth included. By all means, if you have a VPS service that can offer all of this at less than $30 a month, I'd love to consider it. I haven't changed hosting providers in a while, but I haven't found a company capable of meeting the requirements.

Post reply on HN