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.
"Note that is warning in the url bar is only in Firefox Nightly and Firefox Developer Edition. This has not been released to Firefox Beta and Firefox Release."[0]
So this is not a security feature that most end users can rely on, yet.
I use DE, so I have been seeing these for a little while, but I think even in the stable channel you can toggle the security.insecure_password.ui.enabled param to true in about:config.
Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today?
Or like "did you know your house COULD have been ransacked today, but it didn't happen!!"
Now all my users are going to hear that my site is insecure, when nothing at all changed.
How long ago did they announce that? I think just a couple months? They should have announced this much sooner.
It's going to hit me hard as my site is pretty niche and driving even more people away is the last thing I hoped for :( My shared hosting doesn't offer Let's Encrypt, and makes me pay to "install" a free certificate anyway. So I have to move everything to a different web host.
> 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?
"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?
Until users stop using the same password everywhere, your aquarium website is effectively the security for all your users accounts, including their bank.
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?
> 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.
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.
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.
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.)
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.
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.
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)...
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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...)
> 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.
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
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.
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.
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.
> 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.
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.
> 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?
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.
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.
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?
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.
I am not a security expert, but as I understand it, passwords sent in the clear are vulnerable to being intercepted. Even if users of your site don't have much to worry about from those accounts being compromised (this may or may not be true), lots of people use the same password for more than one login, so their accounts on other sites could be compromised too.
That's definitely a significant security risk, even if it wasn't being explicitly labeled before now. It sucks for independent website operators like you, but I'd probably blame your hosting for making it difficult to secure your site rather than browser vendors for protecting their users.
(And, additionally, they tend to fuck over customers who paid for their money. "100$ free credit!". "You only need to pay 5$ to activate your free credit!". "Sorry, but because you didn’t use it, we removed your free credit!")
Dreamhost is in that price range and has LetsEncrypt built in (it's just a checkbox when configuring the domain). I don't use them for my real projects but it's great for blogs and low traffic sites (a couple thousand users should fair fine I'd think).
LDHosting's shared hosting costs me 35€/year, gives 5GB of disk space and lets me upload my own cert for free. I've been with them for a few years and the uptime has been excellent.
I think you could probably just point your DNS at Cloudflare to proxy your site through them; their service includes SSL plus some extras like caching and such for free. I've used them for a handful of projects and it's worked great.
Cloudflare will provide you with certificates they generate, that they verify but won't be accepted by anyone else. (No cost because of that) - this keeps the data secure between you are them. Obviously, you are still trusitng cloudflare in the middle, but still less trust required.
If you can install a certificate, you can already get a real one from Lets Encrypt (you don't actually need to run their client on the server). The problem is that many shared hosting services are still stuck in the past, and don't let you use SSL/TLS at all.
Without running the client, that means manually changing the cert for expiry, which is very short on LetsEncrypt certs. That introudces the possibility of forgetting or messing it up.
I agree that the best option is for shared hosts just to build in support for LetsEncrypt.
Right, so I've currently got CloudFront in front of it, but doesn't that move the problem? Now the connection between CloudFront and S3 is unencrypted.
(I'm probably understanding this wrong, but I'd like to understand why.)
I'm personally in favour of Cloudflare as the simplest solution - even simpler than letsencrypt. However - there are a few caveats. They tend to hit some countries with a Captcha unless you disable it. Might not be an issue. Their "Flexible SSL is controversial as it only encrypts from client to them - not from them to the server. Personally I think this covers the most obvious threat models and is probably "good enough" for the a lot of use cases.
You have a few thousand active monthly users (since it's a web app that requires an account, I'm assuming that corresponds to 50-100k page views per month) and you can't recoup 10-20 EUR a month to cover server costs?
I think it's time for a bit of light monetization.
Maybe your website has some important information and the user is just unaware of the dangers when entering his credentials on your website. Good for him, now firefox is warning him. He can choose to continue or not. Fortunately, if your website doesn't really hold any sensitive information then the user will go forward.
The market demand will naturally require that all shared hosts start offering some sort of free HTTPS as webmasters such as yourself will simply be required to migrate somewhere where $hosting + $HTTPS is cheaper. This means shared hosts may start integrating with services like Let's Encrypt to save costs.
In fact you could be proactive and announce to your shared host that for this reason you will be relocating. Let them know there will be a trend of other webmasters relocating for the same reason.
As more and more website features (passwords, geolocation) start requiring HTTPS by browsers we will naturally approach the point where HTTPS is free and ubiquitous, at which point everybody wins.
I agree. I don't think I'm going to tell them until after I moved though :p In any case they are hostgat0r and while the service is good overall, I hear they've been bought and it's not quite as good as it used to be. They gave me SSH, and even moved server when my site was being a bit sluggish (optimized the queries since)... so hmm.
I genuinely don't have bad things to say about the hosting performance itself. But the documentation on their site is so bad, it alone makes me want to move on. Tired of spending hours trying to find the procedure to do this or that. And their live chat tkes forever to reply.
Matter of fact, they require a fee for an external certificate, and then apparently you have to buy a static IP too. So another option is to upgrade the shared hosting plan, to the one that has a SSL bundled in. But.. then it works only on one domain AFAIK, so if my app also has a forum , I still need a second certificate! WHat if I want an API on another subdomain like api.foobar.com ?
Yet another certificate.
So I think I'll just have to move to a Let's Encrypt aware hosting.
>Or like "did you know your house COULD have been ransacked today, but it didn't happen!!"
>Now all my users are going to hear that my site is insecure, when nothing at all changed.
I'm not sure you should be allowed to drive a webserver.
Your site's server is just one node in the chain of nodes between your server and the browser. Any one of these nodes could be malicious and tamper with the data in either direction. In other words, this isn't about just your node, it's about all nodes.
With the caveat that while the password will be encrypted from the browser to Cloudflare, it will still be transmitted as plain text from Cloudflare to your own server if your server doesn't support HTTPS.
Actually, Cloudflare offer you certs they sign (which wouldn't be trusted by others, but they verify), that you can use to encrypt from the server to them. You still have to trust Cloudflare, but it's not plain text from cloudflare to your server.
If you mean the case where you literally can't serve under HTTPS, it's not just getting the cert that is the problem, in most cases running a local proxy of something that will would fix it, although I accept there are cases (cheap shared hosting, I guess) where that's not an option.
In some cases you have the ability to add certs, but not to run the LetsEncrypt software (e.g: shared hosting) - with the short expiry date on LetsEncrypt certs, doing it manually is error-prone.
Which is not really a true https, depends on your view, but the flexible plan is not encrypted to the source server as one might expect. But if it's possible to set up things that way, it is https, i guess.
In my country and probably a lot more, you'd be held legally responsible if by any means customer data would leak out. Be it stuff sent over a wire unencrypted, or an account with administrator access being compromised due to unencrypted password transfer.
I dare you to go to a hacker or security conference once, just for kicks. Connect to any wifi there, log in. See what happens.
I don't have "customers" though. I thought this was implicit but maybe I needed to clear that up. Sure makes no difference to security. But that is the consideration when Google pushes everyone to have to buy SSL, even those who just have a hobby. I've just been venting frustration a little bit as to seeing the web change from the playground it used to be to a much more regulated thing, but so it goes. Times change :)
That's the point. SSL/TLS is a standard feature nowadays. If you're a web host and you don't support certs or charge some unreasonable fee for adding them (and I'm well aware there are far too many of these out there), then you need to be losing business fast. Your customers should be moving to better competitors. This measure just accelerates this process.
True, it's just the transition atm is a bit painful.
My host is asking ~80 USD for multi domain SSL. It's not that bad, but they don't support Let's Encrypt yet afaik. Are they aware of this and trying to cash in on people who don't want the hassle of moving their sites?
On the other hand, if I buy there is none of that "auto renew" business...
You're leaving your users vulnerable because you can't be bothered to do things correctly. You are not the wronged party here, they are, and you're just finally being pushed into doing it right.
Any web host that doesn't offer SSL by default, for free, is offering an inferior product. I worked on my university's web host from 2006-11 and we put a lot of work into making sure people could use HTTPS whenever they wanted, despite technical limitations (mod_vhost_ldap and SNI don't play well together), and that was a volunteer project, well before the current era of free certs.
If this change convinces people not to use commercial web hosts that don't offer SSL, it will have done a good thing for the web.
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.