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

101–110 of 419 posts

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

#101

Post by michaelmior »

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.

> takes 5 minutes

This is entirely dependent on how your site is hosted. For some shared hosting platforms, it may not be possible at all.

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

#102

Post by bphogan »

michaelmior wrote: post #98
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…

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

Seconding this, because this is what I do for one of my projects.

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

#103

Post by michaelmior »

the_duke wrote: post #99
johndoe4589 wrote: post #88

Earlier quoted context omitted.

Their IT guy?? There are gazillions of people like me who have a blog, or some small project that has a small audience of tens to just a few thousand users. All these people now have to fork for SSL, or have to move everything to a different shared hosting that supports Let's Encrypt.

Right now, you can just put Cloudfront in between. It's free, and takes maybe 5 minutes to sign up and adjust your DNS entries. Of course relying on a provider that might cancel the free plan at any time is not ideal, but worst case you just have to revert your DNS and it's done.

I assume you mean Cloudflare and not Cloudfront. While you could use Cloudfront, AFAIK there's no free option. (Aside from the usage you get as part of the AWS free but that is time-limited.)

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

#104

Post by baby »

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…

So what? It's the harsh reality of unsecure http.

Maybe your website has some important information and the user is just unaware of the dangers when entering his credentials on your website. Good for him, now firefox is warning him. He can choose to continue or not. Fortunately, if your website doesn't really hold any sensitive information then the user will go forward.

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

#105

Post by oh_sigh »

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…

Why do you have a password field on a http site?

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

#106

Post by caconym_ »

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…

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 it wasn't being explicitly labeled before now. It sucks for independent website operators like you, but I'd probably blame your hosting for making it difficult to secure your site rather than browser vendors for protecting their users.

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

#108

Post by mike-cardwell »

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…

Yes. One of the positive aspects of this change is that it punishes the people who are either unable or unwilling to migrate to SSL.

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

#109

Post by ocdtrekkie »

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.

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 needs, like banks and major corporations. This led, IMHO, to a complete failure to recognize a lot of other uses for the Internet, and so their solutions fail to adequately account for them.

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

#110

Post by dTal »

guscost wrote: post #11
bsimpson wrote: post #5

Earlier quoted context omitted.

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…

> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways. For anyone who is wondering what these ways are, here are a couple: 1) Backspace is a crufty special case 2) What happens when someone highlights text in the input box and types over it?

More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days.

So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about?

You certainly can't get away with just wiring keystrokes to a field.

Post reply on HN