Live data from Hacker News

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

security.googleblog.com

271–280 of 419 posts

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

#271

Earlier quoted context omitted.

As with most things, progress isn't clean or easy. Shifts in policy or practice cause disruptions, and then people adjust. The world is a dynamic place. Software is no exception. SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. The question is whether the benefit of the disruption outweighs the cost. Browser-makers decided t…

> SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. I keep hearing this, but failing to see it. Since OpenSSL's inception.

But that's exactly my point. Perhaps we needed this to push us?

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

#272
post #19

Earlier quoted context omitted.

It's one of the few things they do that I can't find a reason they would be financially motivated to do so, other than increase developers' opinions about the company as a whole, which is a good thing for all.

google competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free? sorry to say, but https is not an altruistic move by google.

This is ascribing an absurd level of Machiavellian intent to Google. Why can't people just accept that occasionally, Google engineers do stuff that isn't profitable to the parent company?

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

#274

Earlier quoted context omitted.

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.

[deleted]

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

#275
post #259

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?

Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay. (Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)

I have this exact problem with LastPass. One of my few pain points with it.

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

#276

Earlier quoted context omitted.

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

10/18/2016

> Distrust certificates with a notBefore date after October 21, 2016

Just in time!

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

#277
post #239

Earlier quoted context omitted.

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.

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?

Wouldn't that essentially give an attacker a nice list of websites where the user uses the same credentials?

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

#278
post #259

Earlier quoted context omitted.

Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay. (Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)

I have this exact problem with LastPass. One of my few pain points with it.

You can define equivalent domains in LastPass to solve that.

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

#279

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.

If the only thing you host is a small blog without ads on a server that you have complete control over and spun up last month or something, sure it's 5 minutes. In the real world, for many commercial operations, and especially for legacy code, there can be significant hurdles. For example, it took the NY Times 2 years to move to HTTPS, significantly more than 5 minutes, and they haven't even migrated 100% yet. https:…

If you have 3rd party ads on your login page, you're doing something very, very wrong and you deserve to have all kinds of warnings flashing up.

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

#280
post #239

Earlier quoted context omitted.

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.

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?

[deleted]
Post reply on HN