[twblalock]

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

[Yver]

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

[onion2k]

Until users stop using the same password everywhere, your aquarium website is effectively the security for all your users accounts, including their bank.

[sametmax]

+1. So much +1.

[johndoe4589]

That is 100% correct and I never questioned that in my comments here.

I have to realize I'm not the lambda user I guess, as it's obvious to me to use a different passsword betwene my main emails and other services.

It's certainly better for users to IMPLEMENT SSL. But to outright tell them a site is "insecure" is bully-ish from Google, and a half baked approach from them. How about they disrupt this ridiculous SSL certificate market instead? But they don't have the balls to do that so it's the website owners that are paying the cost.

Not to mention Let's Encrypt is something that need to be renewed and how long will it work or be reliable?

But anyway, not like we have a choice right!

[azernik]

> How about they disrupt this ridiculous SSL certificate market instead?

They have. It's called Let's Encrypt, which is sponsored by (among many other companies) Google.

> But anyway, not like we have a choice right!

No. You do not. Browsers are already beginning to shut off certain features (like location access) for non-HTTPS sites, and HTTP/2 will only be implemented for encrypted connections. This has been coming for years, and the industry has made herculean efforts to make the process easy for service providers.

Deal with it. And if you're frustrated? This, of all fora, is not the place for fact-agnostic venting.

[a_imho]

How is that the websites fault?

[onion2k]

It isn't the website's fault that users do things wrong. It's the users' fault. However, it is the website developer's job to mitigate obvious problems. We know that users do things that are stupid so we have to work a little harder. We have to build products that recognise what the basic minimum standard is, and then try exceed it. If you're transferring passwords across the internet in plaintext then you haven't managed to do that and you need to try harder.

[TallGuyShort]

Because it's just another down-side of an already bad idea that has an easy solution.

[flukus]

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.

[mseebach]

It's also important to remember that grabbing a password for a higher-value property is only one kind of attack. An attacker could use a compromised account to log in to the aquarium forum and subtly post malware infected links (or change existing links after other members have validated the original one). They can use the account for social engineering ("Hey guys, I'm sorry it's off topic, but my son has cancer and we're having trouble paying the bills, can you please donate here?") - etc. This will hit a large audience of often less technically sophisticated targets, in what for these small hobbyist sites is often a high-trust environment. All without crossing the boundary of the compromised site.

[dsp1234]

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?

[jayd16]

Besides issues like requiring javascript or something, its usually not a useful step. The hash of the password can be stolen just as easily as the password itself. You've just made a new password.

If you salt the password with the url, all you've done is made a unique password per website which is what you were supposed to be doing anyway.

[dsp1234]

The point was for the browser to warn the end user about password re-use.

The browser doesn't need javascript to see the contents of a password field, or to show an indicator in the browser's chrome. It's the browser.

If you salt the password with the url, all you've done is made a unique password per website which is what you were supposed to be doing anyway.

Note that browsers can already store password lists (ex: Chrome settings, search manage passwords). There would just be an extra step to compare those passwords together.

[geofft]

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

[nickik]

Its a real problem, in the new anti-phishing protocols (U2F/UAF) have some ideas.

The Web Origin Concept - https://tools.ietf.org/html/rfc6454

The also require the server to provide a list of Origins that are valid for the protocol, if the domain your logging into is not in the list, the challenge of the server will not be signed. Its called AppID in the protocol.

See: https://fidoalliance.org/download/

[austinsharp]

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

[tempestn]

You can define equivalent domains in LastPass to solve that.

[peeters]

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

[ufmace]

Sounds kind of rube-goldberg-y compared to automatically generating and managing a unique password for every site.

[flukus]

Probably not a bad idea. But at that point you're fighting human nature.

[ripdog]

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]

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 to https://abc.com).

[cr0sh]

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

How do they do this? How do you set up an SSL cert on a shared host (aren't SSL certs tied to an IP)?

I have a site on a virtual host (via Hurricane Electric), and I don't want to move to another hosting provide (cloud hosting) if I can avoid it. But unless something has changed (which I admit, it may have - I am not up on all the latest web hosting tech), my understanding was that you can't have an SSL cert on a virtual host.

[joshstrange]

This is no longer the case: http://webmasters.stackexchange.com/a/13990 You can have multiple sites on the same IP all have their own TLS cert.

[cr0sh]

After I posted I did some research and saw that, but thanks for posting the clarifying link.

I also found that my hosting provider (HE) does have something where on vhosts they have an SSL side - but as far as I can see they don't support (that is, by default or whatnot) Let's Encrypt certs.

However, digging deeper - there may be a way for me to set it up; I'd need to use a different LE client that doesn't need root access (there are a few), then I'd also have to set up a cron task to renew the cert every (< 90) days or so. Then update all of my pages, templates, code, etc to use https instead of http where applicable...a not insignificant amount of work, but doable.

I might still fire an email over the HE - maybe it's finally time for me to move away from them and over to Digital Ocean or something that supports LE certs out-of-the-box (I'd still have to fix the links on my site - but then again I've thought about just revamping my site again - it's due for it)...

[prawn]

Wouldn't putting someone (whose server experience level warrants shared hosting) in charge of a VPS create more security issues?

[ripdog]

Linux is fairly secure by default, so most of what that admin has to do is just not screw it up. Turn off SSH passwords and disable root login, then read a hardening guide for their particular tech stack. Once it's set up, you just need to log in once in a while to update software.

Also backups, if it needed to be said.

[johndoe4589]

Well I can configure a Linux vm for development I guess I could handle that.

Wouldn't these VPS come with a sensible default?

[bitJericho]

It's the only way to learn...

[johndoe4589]

How cheap? Would you have a suggestion? Thanks.

[jacurtis]

DigitalOcean.com starts at $5/mo for a VPS that is going to be faster and better than most shared hosts would be. Of course you can scale it up and down as needed. Their $10 a month server is actually really powerful for any sites that get less than say 10,000 visits a day. They even have one-click wordpress installs now among many other open source programs.

I use DigitalOcean now for almost all of my sites. I have abandoned wordpress lately and so I am using custom built sites for all my projects. DigitalOcean is awesome.

[azernik]

Low-end dedicated VPS runs around $5/month. See DigitalCloud or Amazon Lightsail.

If you want to save a bit more money and are willing to commit to a 1-year contract, you could even get a t2.nano instance from Amazon EC2 at around $3/month.

[tortasaur]

If you check out deal aggregation sites like LowEndBox you can usually get one even cheaper than that (I pay $20 annually for mine)

[jrockway]

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.

[mysticmarvel]

Do you ask for personal information as part of your signup process? First name, last name, email address etc? If you don't encrypt the data or take basic precautions against unauthorised access you're likely breaking Data Protection law.

If you've already implemented a web server with SSL then "weak cyphers" might bother you. As you don't already have it configured, you're no worse off configuring a fully TLS 1.2-compliant web server with SHA256 signed certs and ChaCha20-Poly1305 cypher suite. It's just a configuration option if you're doing it for the first time.

[michaelbuckbee]

I think of it like herd immunity. Users typically reuse passwords between sites, so if leaches the passwords out of the aquarium forum they may get their Gmail password as well, etc.

[msbarnett]

Yes, every site should be. The average user shares their niche acquarium site login username/password with their gmail login and bank and everything else.

In the physical universe we occupy a given user's most security-sensitive site is exactly as vulnerable as their least security-conscious site. It behooves us as professionals to take that fact seriously.

[Arizhel]

>Yes, every site should be. The average user shares their niche acquarium site login username/password with their gmail login and bank and everything else.

So what? Not every site has a login, or stores details about users. What about sites that are purely informational? If a site doesn't have passwords, why are you worried about users re-using passwords?

[johndoe4589]

Not to mention, underlying my sentiment in my comments here, is that basically EVERY website out there can be broken. We hear about this every day now, Yahoo, Dropbox, and on and on.

If someone skilled wants to break your site, and they have a good reason to, they will. This is especially true for small sites / forums / blogs which the owners can not reasonably protect the way a corporation like Facebook can.

So on those smaller "hobby" / community sites it should be a given that using good passwords and precautions is necessary, as it always has been and a lot of people in my audience use dummy emails and tend to shy away from real names, etc.

So that's my main beef. Google is bullyish here, and is hitting the small guys, the pet projects, the "garage band" developers, and doesn't give these people a simple upgrade path. Hence, more and more I feel like pet projects and websites are going to disappear in favor of using third parties and I think this is a downside to all this fear mongering.

It's necessary but it's a painful change. The web isn't the playground that it used to be and I guess that's just the way it is.

[mseebach]

> basically EVERY website out there can be broken

False equivalence. There is a huge difference between the significant effort required to break these big sites, and then a script-kiddie running a wifi sniffer at a Starbucks.

[azernik]

> Not to mention, underlying my sentiment in my comments here, is that basically EVERY website out there can be broken. We hear about this every day now, Yahoo, Dropbox, and on and on.

Yes. They can. By putting in a substantial effort, in order to break big sites, which probably isn't worth it for the small fry. But if you're not using SSL, they don't need to put in the effort on site-specific exploits - they just need to be listening on the public wi-fi.

> So on those smaller "hobby" / community sites it should be a given that using good passwords and precautions is necessary, as it always has been and a lot of people in my audience use dummy emails and tend to shy away from real names, etc.

Ummmm.... what exact hobby/community sites are you talking here? Judging by most studies on the matter, I think you have an inflated opinion of your users' security practices.

[johndoe4589]

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]

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

[bartread]

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

Really? https://letsencrypt.org/ Chrome is listed amongst the major sponsors.

I don't even use, or have much love for, LetsEncrypt as it happens because it was a PITA to set up with node when I tried it. But even without that getting and using a certificate issued by Cloudflare was easy.

Creating a self-signed certificate for dev and test is also pretty easy. It just takes a handful of commands in bash: http://www.akadia.com/services/ssh_test_certificate.html. It's the work of literally 5 minutes.

[pc86]

What legitimate reason do you have not to use SSL? It's free.

Are you really saying that your site would be no more secure with SSL? Because that is objectively, provably false. If your clients are paying you to make sites like this that is borderline professional malpractice.

[Vinnl]

If people entered their good passwords on your site without noticing that it was unencrypted, then great, they should now consider that password compromised... As a user, as soon as I notice it's unencrypted, I'm _going_ assume the password is also probably not encrypted nor salted, and other users will probably have done so.

(Of course, even better would be a different password per site, but...)

[ufmace]

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

Pretty sure they did. Sorry, but if you're going to be the one responsible for keeping a website online, you have at least some responsibility to keep an eye on tech news just to see if there are any major security breaches or changes in how the web will work coming up. If you don't have time to do this, you really ought to take the site down and move the functionality to some other type of hosting where somebody else takes care of this for you. Otherwise, you may find your site hacked and running a spam server or serving kiddie porn or something one day.

[wfunction]

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

[lucideer]

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]

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.

[sirbearington]

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.

[Hondor]

This is actually a good example. The password clearly isn't protecting anything. It's a tutorial on how to make a password field! Nobody is going to put a valuable password in there.

[msbarnett]

And now they'll have an extra reminder not to enter a real password in an example field. Seems good to me.

[wfunction]

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

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]

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

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.

[ledriveby]

Can't do that when JS can access the field contents asynchronously via the DOM. Blocking JS execution for a user prompt wouldn't fly, either.

[lostsock]

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]

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]

The point is the result is the same - Chrome will flag that page is insecure.

[cmg]

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]

And the user will know they shouldn't type a password they want to keep secure into that field. Makes sense to me.