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.
[0] - https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...
"Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen."
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.
1: https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...
Also I love FF.
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.
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?
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?
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.
(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.
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)...
Also backups, if it needed to be said.
Wouldn't these VPS come with a sensible default?
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.
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.
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.
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.
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.
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.
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.
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.
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.
(Of course, even better would be a different password per site, but...)
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.
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?
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.
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'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.
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.
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.
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.
Time to move on I guess.
Does anyone have good hosting suggestions for a web app that has a 1GB database and a few thousand active users?
I can only afford ~10-20 EUR a month on shared hosting atm.
TL;DR: Too expensive.
(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!")
Sounds to me like you can move to a better host that does provide LetsEncrypt and save money on your hosting costs to boot!
9 EUR, 2 cores + 6 GB RAM, 40 GB SSD.
It still baffles me that someone is using shared hosting services and upload their php files via ftp...
I agree that the best option is for shared hosts just to build in support for LetsEncrypt.
Anything I can do other than not using S3?
(I'm probably understanding this wrong, but I'd like to understand why.)
I think it's time for a bit of light monetization.
(Asking users for donations might work where advertisement perhaps doesn't.)
Correct, nothing has changed, it has always been insecure.
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.
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.
Also, you've had a one year notice that this was going to happen: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
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.
I'm not sure you should be allowed to drive a webserver.
Commandeer?
I don't know what you do with a battleship. Helm it, maybe?
Sounds like you'd get arrested for that....
Nothing's changed: Your site really is insecure, it's just that now users know.
A year ago.[1]
[1]: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
Your negligence pose security risk to your users, they should be warned.
So it's an improvement but not entirely a fix.
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.
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.
Do you think web hosts offer SSL by default?
NO they don't. Duh. That's what is annoying in these comments. Everyone seems to shrug like SSL is standard feature nowadays, except is isn't.
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...
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.