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

+1. So much +1.

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!

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

How is that the websites fault?

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.

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

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.

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.

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?

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.

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.

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

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/

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

You can define equivalent domains in LastPass to solve that.

Yes!!! Thank you!!!

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

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

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

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!

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

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

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.

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

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

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.

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

Wouldn't these VPS come with a sensible default?

It's the only way to learn...

How cheap? Would you have a suggestion? Thanks.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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