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

211–220 of 419 posts

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

#211

Post by [deleted] »

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.

[deleted]

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

#212

Post by [deleted] »

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.

[deleted]

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

#213

Post by icebraining »

ocdtrekkie wrote: post #109
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.

Let's Encrypt is great, but completely useless for... Actually every single website I host. No wildcard certs, the rapid rotation that requires software to renew it regularly, etc. The cost of implementing HTTPS for dozens of sites with no sensitive data is simply not worth it. When companies like Google and Mozilla decided how to handle HTTPS, they decided based on their needs and their perception of everyone else's…

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?

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

#214

Post by technion »

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"

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

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

#215

Post by icebraining »

Symbiote wrote: post #147
fdsaaf wrote: post #100

Earlier quoted context omitted.

> It's increasingly difficult to opt out of browser autofill Good. I hope browsers autodetect these web font tricks and pop up similar warnings. I can't stand when some random website make thinks it can do a better job of credential security than major browser makers.

I think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.

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

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

#216

Post by megablast »

nkkollaw wrote: post #79
dheera wrote: post #47

Earlier quoted context omitted.

A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate…

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.

Bullshit. Not if you have shared hosting. Or 1000 over different situations that you clearly have not thought about.

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

#217

Post by iancarroll »

nommm-nommm wrote: post #116
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.

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

It can indeed take some time to switch over, but why would you intentionally suppress a correct warning in the meantime? There is no good reason to mislead users here.

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

#218

Post by Yver »

twblalock wrote: post #156
johndoe4589 wrote: post #95

Earlier quoted context omitted.

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…

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

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

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

#219

Post by icebraining »

kuschku wrote: post #152
hk__2 wrote: post #54

Earlier quoted context omitted.

They do it for CC numbers too, as outlined in their page for developpers [1]: > To ensure that the Not Secure warning is not displayed for your pages, you must ensure that all forms containing elements and any inputs detected as credit card fields are present only on secure origins. [1]: https://developers.google.com/web/updates/2016/10/avoid-not-...

Do they also do it for IBAN?

The people who decided that the new SEPA payments should include a way for creditors to take people's money using just public information and their signature should be fired. It's like they learned nothing from the billions of dollars wasted from fraud in the credit card system. Payments should always start after an explicit order by the payer to their bank, not just having the payee say "trust me, they totally want me to have this money".

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

#220

Post by nommm-nommm »

iancarroll wrote: post #217
nommm-nommm wrote: post #116

Earlier quoted context omitted.

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

It can indeed take some time to switch over, but why would you intentionally suppress a correct warning in the meantime? There is no good reason to mislead users here.

Because, here in the real world, my paycheck depends on keeping my customers happy.
Post reply on HN