Earlier quoted context omitted.
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…
I know I guess I just have to vent some frustration. 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.
Chrome 56 will mark HTTP pages with password fields as non-secure
321–330 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#322Earlier quoted context omitted.
> 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…
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…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#323Earlier quoted context omitted.
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 ce…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#324Earlier quoted context omitted.
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…
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…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#325Earlier quoted context omitted.
"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?
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 t…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#326Earlier quoted context omitted.
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…
I know I guess I just have to vent some frustration. 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.
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...
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#327Earlier quoted context omitted.
"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?
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 t…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#328Earlier quoted context omitted.
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!
How cheap? Would you have a suggestion? Thanks.
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#329Earlier quoted context omitted.
"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?
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#330Earlier quoted context omitted.
> 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…
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…
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.