10 ms·

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

> 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 that, you're negligent and you should stop doing business with the public. This is a huge red flag. If you really don't think SSL is important, it raises disturbing questions about your approach to security in general. Which other standard security practices have you ignored? Are you using strong hashing for passwords? Are you properly handling input to prevent SQL injection?

wfunction 10y ago
> 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_inputpassword 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?
- lostsock 10y ago
  The password form on that page _IS_ insecure and it's good that the user is given information about that. They can then make the decision about themselves about the lack of security and how it effects them and the page they are on.
- twblalock 10y ago
  Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?
  - madeofpalk 10y ago
    The point is the result is the same - Chrome will flag that page is insecure.
    - cmg 10y ago
      Because it is insecure. Sure, that form doesn't actually do anything, but why not help and train visitors to expect security and know how to spot it? w3schools is for web developers who are learning. Maybe they'll see that the page is marked Insecure and the lesson they'll get from it is that they need to secure their logins.
    - Latty 10y ago
      And the user will know they shouldn't type a password they want to keep secure into that field. Makes sense to me.
- sirbearington 10y ago
  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.
  - wfunction 10y ago
    > 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 exists that doesn't mean the page is insecure.
    - andrewstuart2 10y ago
      If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality. If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. Might as well swap it for an input and, voila, your users won't have any warnings.
      - wfunction 10y ago
        > If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. You don't think it was adding anything in the example page I just linked you to?
        andrewstuart2 10y ago
        Only a false sense of security. Since the page is loaded as plain text, it can also be altered by anyone with network access between the server and the user. Javascript can be very trivially injected that simply sends each keydown event to the server, giving away the user's "hidden" password. So even if the code you wrote doesn't ever send the password input to the server, that doesn't mean code hasn't been injected by some third party by the time it gets to your customer/user.
- lucideer 10y ago
  I don't see why you (or w3schools) would object to a warning being shown on that page. It's put forward as an example, it shouldn't be treated as real and something requiring security, so showing a generic warning confirming it's not secure is perfectly harmless and even expected
- geofft 10y ago
  This is such a weird argument to have when incentivizing w3schools to use SSL would be a good thing. They can clearly afford the cost of acquiring, installing, and maintaining an SSL certificate. And as a website that teaches people about the web, they should be setting an example by using SSL. Alternatively, they should be setting an example by demonstrating that password prompts that aren't over SSL will cause warnings. But even if it were legitimate for w3schools to not use SSL, security is about tradeoffs, and the tradeoff is that it's absolutely worth displaying a warning on one page that arguably doesn't need instead of not displaying it on millions of pages that definitely do.
Yver 10y ago
"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?
- jrockway 10y ago
  I think the use case is people browsing your site in a coffee shop. They wouldn't shout their password for everyone in the room to hear, but that's exactly what their computer's doing. Yeah, probably nobody overhearing the password is going to use their account to start posting embarrassing nonsense. But it's good for their user agent to inform them that that could happen. State-sponsored actors aren't going to try to brute-force the encryption so they can post to your aquarium forum, that's true.
- ripdog 10y ago
  Yes. Every website. Because if only the sensitive sites are strongly encrypted, then bad actors and authorities know exactly where to focus their efforts in trying to steal information. When everyone is strongly encrypted, attackers are stretched much more thinly. Besides, it's easy and free these days. Unless, apparently, you use some crappy shared hosting provider. Get a VPS, man! They're cheap!
  - joshstrange 10y ago
    Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. I was setting up a WP blog for a family member the other day and saw the option and it was super easy. I've added to my backlog to go turn it on for all my other sites as soon as I've confirmed it won't break anything (ie. loading assets using absolute urls that use http. But even that is easy with this WP plugin I found that rewrites all url's you list in pages/posts and while it's probably meant for changing the URL of your blog from abc.com to def.com it works flawlessly with going from http://abc.com http://abc.com to https://abc.com https://abc.com).
johndoe4589 10y ago
I've never said SSL isn't important nor that I don't care about it. My beef is how Google forces this change on everyone, but at the same time haven't the balls to shake things up and make SSL easily available for everyone. Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. THAT is lame on Google. But I guess this is the transition now that is going to be painful for lots of small sites / apps like me. I genuinely never heard this a year ago so they shoudl also have made a big announcement of this much sooner to give time to small guys like me to prepare. As for the general security question. I understand the "insecure" aspect is mainly related to public networks, and indeed nowadays it's becoming increasingly coming to use public wifi networks on the go. But some of reaction is also implicitly that using a good password was always a good measure before or after this change. Hence saying something is "insecure" outright is somewhat bullyish on Google's part. Of course it's insecure, so is using a car. You're making lots of assumptions. My passwords are encrypted and "salted". My site properly handles input I'm not that dumb thank you very much. I like to question decisions like these. Just have to vent a bit I guess. Yes, it's a good thing, but I can't help to think it's still bullyish and a half hearted solution from Google. In any case it looks like the first notice of this won't be as bad as I thought, it's a small "Not Secure" text... won't scare users too much while I move host and add SSL.
- azernik 10y ago
  > Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. Which is not Google's business. Google does not have the obligation to make your job easier. As a browser vendor, however, it does have the obligation to protect its users. > But some of reaction is also implicitly that using a good password was always a good measure before or after this change. Hence saying something is "insecure" outright is somewhat bullyish on Google's part. Of course it's insecure, so is using a car. There is no such thing as absolute security. That does not mean that security is a meaningless adjective. Sending passwords over unencrypted HTTP is demonstrably less secure than sending over HTTPS - it opens up the user account to compromise from any network host anywhere on the path from them to your server.

wfunction 10y ago

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

lostsock 10y ago
The password form on that page _IS_ insecure and it's good that the user is given information about that. They can then make the decision about themselves about the lack of security and how it effects them and the page they are on.
twblalock 10y ago
Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?
- madeofpalk 10y ago
  The point is the result is the same - Chrome will flag that page is insecure.
  - cmg 10y ago
    Because it is insecure. Sure, that form doesn't actually do anything, but why not help and train visitors to expect security and know how to spot it? w3schools is for web developers who are learning. Maybe they'll see that the page is marked Insecure and the lesson they'll get from it is that they need to secure their logins.
  - Latty 10y ago
    And the user will know they shouldn't type a password they want to keep secure into that field. Makes sense to me.
sirbearington 10y ago
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.
- wfunction 10y ago
  > 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 exists that doesn't mean the page is insecure.
  - andrewstuart2 10y ago
    If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality. If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. Might as well swap it for an input and, voila, your users won't have any warnings.
    - wfunction 10y ago
      > If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. You don't think it was adding anything in the example page I just linked you to?
      - andrewstuart2 10y ago
        Only a false sense of security. Since the page is loaded as plain text, it can also be altered by anyone with network access between the server and the user. Javascript can be very trivially injected that simply sends each keydown event to the server, giving away the user's "hidden" password. So even if the code you wrote doesn't ever send the password input to the server, that doesn't mean code hasn't been injected by some third party by the time it gets to your customer/user.
lucideer 10y ago
I don't see why you (or w3schools) would object to a warning being shown on that page. It's put forward as an example, it shouldn't be treated as real and something requiring security, so showing a generic warning confirming it's not secure is perfectly harmless and even expected
geofft 10y ago
This is such a weird argument to have when incentivizing w3schools to use SSL would be a good thing. They can clearly afford the cost of acquiring, installing, and maintaining an SSL certificate. And as a website that teaches people about the web, they should be setting an example by using SSL. Alternatively, they should be setting an example by demonstrating that password prompts that aren't over SSL will cause warnings. But even if it were legitimate for w3schools to not use SSL, security is about tradeoffs, and the tradeoff is that it's absolutely worth displaying a warning on one page that arguably doesn't need instead of not displaying it on millions of pages that definitely do.

Yver 10y ago

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

jrockway 10y ago
I think the use case is people browsing your site in a coffee shop. They wouldn't shout their password for everyone in the room to hear, but that's exactly what their computer's doing. Yeah, probably nobody overhearing the password is going to use their account to start posting embarrassing nonsense. But it's good for their user agent to inform them that that could happen. State-sponsored actors aren't going to try to brute-force the encryption so they can post to your aquarium forum, that's true.
ripdog 10y ago
Yes. Every website. Because if only the sensitive sites are strongly encrypted, then bad actors and authorities know exactly where to focus their efforts in trying to steal information. When everyone is strongly encrypted, attackers are stretched much more thinly. Besides, it's easy and free these days. Unless, apparently, you use some crappy shared hosting provider. Get a VPS, man! They're cheap!
- joshstrange 10y ago
  Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. I was setting up a WP blog for a family member the other day and saw the option and it was super easy. I've added to my backlog to go turn it on for all my other sites as soon as I've confirmed it won't break anything (ie. loading assets using absolute urls that use http. But even that is easy with this WP plugin I found that rewrites all url's you list in pages/posts and while it's probably meant for changing the URL of your blog from abc.com to def.com it works flawlessly with going from http://abc.com http://abc.com to https://abc.com https://abc.com).

johndoe4589 10y ago

I've never said SSL isn't important nor that I don't care about it. My beef is how Google forces this change on everyone, but at the same time haven't the balls to shake things up and make SSL easily available for everyone. Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. THAT is lame on Google. But I guess this is the transition now that is going to be painful for lots of small sites / apps like me. I genuinely never heard this a year ago so they shoudl also have made a big announcement of this much sooner to give time to small guys like me to prepare. As for the general security question. I understand the "insecure" aspect is mainly related to public networks, and indeed nowadays it's becoming increasingly coming to use public wifi networks on the go. But some of reaction is also implicitly that using a good password was always a good measure before or after this change. Hence saying something is "insecure" outright is somewhat bullyish on Google's part. Of course it's insecure, so is using a car. You're making lots of assumptions. My passwords are encrypted and "salted". My site properly handles input I'm not that dumb thank you very much. I like to question decisions like these. Just have to vent a bit I guess. Yes, it's a good thing, but I can't help to think it's still bullyish and a half hearted solution from Google. In any case it looks like the first notice of this won't be as bad as I thought, it's a small "Not Secure" text... won't scare users too much while I move host and add SSL.

azernik 10y ago
> Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. Which is not Google's business. Google does not have the obligation to make your job easier. As a browser vendor, however, it does have the obligation to protect its users. > But some of reaction is also implicitly that using a good password was always a good measure before or after this change. Hence saying something is "insecure" outright is somewhat bullyish on Google's part. Of course it's insecure, so is using a car. There is no such thing as absolute security. That does not mean that security is a meaningless adjective. Sending passwords over unencrypted HTTP is demonstrably less secure than sending over HTTPS - it opens up the user account to compromise from any network host anywhere on the path from them to your server.