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

181–190 of 419 posts

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

#181

Post by cmg »

madeofpalk wrote: post #171
twblalock wrote: post #167

Earlier quoted context omitted.

Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?

The point is the result is the same - Chrome will flag that page is insecure.

Because it is insecure. Sure, that form doesn't actually do anything, but why not help and train visitors to expect security and know how to spot it?

w3schools is for web developers who are learning. Maybe they'll see that the page is marked Insecure and the lesson they'll get from it is that they need to secure their logins.

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

#182

Post by michalskop »

johndoe4589 wrote: post #126
caconym_ wrote: post #106

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.

Scaleway has 50G disc and 2G memory for 3€(+VAT)/month

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

#183

Post by andrewstuart2 »

wfunction wrote: post #178
sirbearington wrote: post #175

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.

> who knows what else the user is protecting with that password How does it even matter when the password field is never even read? There are better alternatives. Chrome could just give a security error when the password is actually accessed. Or alternatively it could prevent the page from storing any data locally or sending any data to any server if the password field is non-empty. Just because a password field exis…

If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality.

If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. Might as well swap it for an input and, voila, your users won't have any warnings.

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

#184

Post by Latty »

madeofpalk wrote: post #171
twblalock wrote: post #167

Earlier quoted context omitted.

Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?

The point is the result is the same - Chrome will flag that page is insecure.

And the user will know they shouldn't type a password they want to keep secure into that field. Makes sense to me.

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

#186

Post by Latty »

simcop2387 wrote: post #149
robbiewxyz wrote: post #140

Earlier quoted context omitted.

I think you could probably just point your DNS at Cloudflare to proxy your site through them; their service includes SSL plus some extras like caching and such for free. I've used them for a handful of projects and it's worked great.

That said it will still be insecure because of the unencrypted path from cloudflare to you server but it will hire the error

Cloudflare will provide you with certificates they generate, that they verify but won't be accepted by anyone else. (No cost because of that) - this keeps the data secure between you are them. Obviously, you are still trusitng cloudflare in the middle, but still less trust required.

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

#187

Post by wfunction »

andrewstuart2 wrote: post #183
wfunction wrote: post #178

Earlier quoted context omitted.

> who knows what else the user is protecting with that password How does it even matter when the password field is never even read? There are better alternatives. Chrome could just give a security error when the password is actually accessed. Or alternatively it could prevent the page from storing any data locally or sending any data to any server if the password field is non-empty. Just because a password field exis…

If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality. If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that passwo…

> If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway.

You don't think it was adding anything in the example page I just linked you to?

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

#188

Post by ec109685 »

BinaryIdiot wrote: post #119
hackinthebochs wrote: post #78

Earlier quoted context omitted.

Honest question, who is in a position to tap your connection such that this becomes a serious security concern? IT staff at your company? The admins at your ISP? The NSA? I'm assuming that public wifi has session-specific encryption keys. I don't see these as the kinds of concerns that would warrant the kind of panic that some people seem to show over HTTP.

> who is in a position to tap your connection such that this becomes a serious security concern? When you use HTTP everything is sent in plain text. This means... - Anyone on the same network as you can see all of your traffic. This includes company networks, coffee shop wifi, your house, the library; any place that has a WiFi network. Caveat: it's possible to use network isolation to hide your traffic but this is cr…

If I have two devices connected to a switch, how can they see each other's traffic?

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

#189

Post by Latty »

bsuh wrote: post #125
michaelmior wrote: post #98

Earlier quoted context omitted.

It may not be an option for you, but you could consider using a free proxy service such as Cloudflare.

With the caveat that while the password will be encrypted from the browser to Cloudflare, it will still be transmitted as plain text from Cloudflare to your own server if your server doesn't support HTTPS. So it's an improvement but not entirely a fix.

Actually, Cloudflare offer you certs they sign (which wouldn't be trusted by others, but they verify), that you can use to encrypt from the server to them. You still have to trust Cloudflare, but it's not plain text from cloudflare to your server.

If you mean the case where you literally can't serve under HTTPS, it's not just getting the cert that is the problem, in most cases running a local proxy of something that will would fix it, although I accept there are cases (cheap shared hosting, I guess) where that's not an option.

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

#190

Post by elastic_church »

polygot wrote: post #41

I hope they do this for CC numbers too, because I know of a website I had to use that passed your Name, address, CC number, CC exp, amount; the whole shebang over plain ol' http to do a payment shudder .

Would that really prevent you from purchasing?

Like lets say something rare was available for purchase, or music festival tickets that will sell out in 2 more minutes

would your first thought be "woah thanks Chrome you really saved me this time!"

Post reply on HN