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!
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.
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?
(Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)
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.
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 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.
Besides, it's easy and free these days. Unless, apparently, you use some crappy shared hosting provider. Get a VPS, man! They're cheap!
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.
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 these VPS come with a sensible default?
Also backups, if it needed to be said.
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.
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.
State-sponsored actors aren't going to try to brute-force the encryption so they can post to your aquarium forum, that's true.
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.
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.
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?
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.
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.
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.