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

331–340 of 419 posts

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

#331

Post by kuschku »

icebraining wrote: post #227
kuschku wrote: post #163

Earlier quoted context omitted.

So, now we have a single certificate on all routers? What happens if I take apart a router? Or would every router get its own certificate? But then netgear would have to become its own CA. And in either case DNS hijacking is a massive issue.

Or would every router get its own certificate? But then netgear would have to become its own CA. Why? They could just partner with an existing CA, like Cloudflare does with Comodo. And how would DNS hijacking be an issue? The attacker wouldn't be able to produce a valid cert anyway (the router would come with a custom burned-in key that it would use to authenticate itself to the CA and get the cert).

> the router would come with a custom burned-in key that it would use to authenticate itself to the CA and get the cert

I take apart the router, and get a valid certificate. Now I hijack DNS, and get you to connect to me.

HTTPS within LAN for this purpose is useless.

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

#332

Post by kuschku »

icebraining wrote: post #219
kuschku wrote: post #152

Earlier quoted context omitted.

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…

Well, luckily, there is!

SEPA is a bi-directional protocol – if you try to take money from a bank account, the bank can say "nope", and the transaction can fail (with the person trying to pull the money taking the loss).

As banks allow you to configure this – mine allows me to disallow all direct debit, or disallow foreign direct debit, or only allow it from specific companies – this is not an issue.

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

#334

Post by discreditable »

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.

It's pretty interesting to see a few sites loaded over HTTPS that submit forms over HTTP.

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

#335

Post by discreditable »

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.

> now that installing a certificate takes 5 minutes and is free, with Let's Encrypt?

It's only easy if you're using a Linux webserver. In IIS land it's a pain.

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

#336

Post by andybak »

andybak wrote: post #170
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

For some definitions of "insecure".

Hmmmm. -4. I fleshed out my thoughts in slightly more detail in another comment: https://news.ycombinator.com/item?id=13458224

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

#337

Post by discreditable »

pjc50 wrote: post #66
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 .

I'm fairly sure that violates PCI-DSS.

PCI-DSS is okay if you put it in an HTTPS iframe. Many sites I've seen use that workaround.

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

#338

Post by helb »

johndoe4589 wrote: post #123
the_duke wrote: post #99

Earlier quoted context omitted.

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'm running a web app, isn't Cloudflare best for static / semi static content?

It is, but it might work for your app, too – js/css/image caching at CF nodes helps a lot. Moreover, you can disable their cache/cdn features and use it only for SSL.

They even have multiple modes, the "Flexible" one works even with no changes at your server at all. It obviously makes the CFserver transfer insecure, but your users would still get a "green lock", if that's what you're after.

This is from their in-settings help: https://www.cloudflare.com/a/static/images/ssl/ssl.png

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

#339

Post by rimantas »

ocdtrekkie wrote: post #262
stanleydrew wrote: post #241

Earlier quoted context omitted.

This is false. Passwords are only as sensitive as all the data they access. Given that it's impossible for you to know what other data the user is protecting with the same password, you must assume all passwords are as sensitive as the most sensitive data a user might reasonably secure with that password. Do I wish things were different, and that everyone on earth used unique passwords for every site? Of course. But…

As someone who runs like a roleplaying site for like ten people (or several of them), I cannot be responsible for other people's bank passwords, nor should I be punished for daring to host websites without the huge added burden of cost of HTTPS. The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.

You should not be responsible for running any of the sites with this attitude.
Post reply on HN