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

201–210 of 419 posts

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

#201

Post by renownedmedia »

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…

The market demand will naturally require that all shared hosts start offering some sort of free HTTPS as webmasters such as yourself will simply be required to migrate somewhere where $hosting + $HTTPS is cheaper. This means shared hosts may start integrating with services like Let's Encrypt to save costs.

In fact you could be proactive and announce to your shared host that for this reason you will be relocating. Let them know there will be a trend of other webmasters relocating for the same reason.

As more and more website features (passwords, geolocation) start requiring HTTPS by browsers we will naturally approach the point where HTTPS is free and ubiquitous, at which point everybody wins.

Also, you've had a one year notice that this was going to happen: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

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

#202

Post by datguacdoh »

ec109685 wrote: post #188
BinaryIdiot wrote: post #119

Earlier quoted context omitted.

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

Just download Wireshark and you'll have an easy to use tool that'll show you the traffic.

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

#203

Post by lucideer »

malikNF wrote: post #166
derimagia wrote: post #162

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…

In house software isn't an issue: internal staff are not going to go away and use a competitor if they see a security warning. They're just going to learn to live with it.

As for saying "small companies", I really don't see how this has an impact on smaller companies more than others. Certs are free, and trivial to install for any public domain (others in the comments above have mentioned valid problems with non-public domains, which remain to be solved but they are somewhat less affected by this feature anyway).

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

#204

Post by Hondor »

sirbearington wrote: post #175
wfunction wrote: post #160

Earlier quoted context omitted.

> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?

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.

This is actually a good example. The password clearly isn't protecting anything. It's a tutorial on how to make a password field! Nobody is going to put a valuable password in there.

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

#206

Post by nodesocket »

bsimpson wrote: post #5
foota wrote: 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"

Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Loo…

+1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.

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

#207

Post by jensvdh »

Latty wrote: post #189
bsuh wrote: post #125

Earlier quoted context omitted.

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…

Wouldn't he still have to install the Cloudflare certs on his server then? In that case why not get LetsEncrypt?

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

#208

Post by ledriveby »

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…

Can't do that when JS can access the field contents asynchronously via the DOM. Blocking JS execution for a user prompt wouldn't fly, either.

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

#209

Post by icebraining »

Latty wrote: post #186
simcop2387 wrote: post #149

Earlier quoted context omitted.

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.

If you can install a certificate, you can already get a real one from Lets Encrypt (you don't actually need to run their client on the server). The problem is that many shared hosting services are still stuck in the past, and don't let you use SSL/TLS at all.

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

#210

Post by KirinDave »

I've got to say though, that this is a wee bit frustrating as a developer. SSL libraries are terrible, bug ridden, hard to work with, and there are huge sacrifices using a pass-through proxy to offer SSL.

The brittleness of SSL libraries manifests not just in the form of security exploits, but also in the form of delaying the next generation of HTTP technology. Node doesn't support natively support HTTP/2 due to HTTP2 fitting issues [https://github.com/nodejs/NG/issues/8]. Jetty was delayed for Java SLL changes. Same with Go.

If Google wants to make the whole web secure? That's great. But we also need to work on making it simple to secure. So much research goes into novel ciphers and optimal ways to defeat timing attacks, and etc etc, but the spike in complexity means that we're reaching a point where almost no individual or group can approach a correct implementation.

It worries me that we're approaching a point where we're utterly dependent on a security standard no one can understand.

Post reply on HN