Earlier quoted context omitted.
How happy will your customers be when they find out that you're just pulling the wool over their eyes instead of doing your job?
Did you read what I wrote? I do my job but there's only so much I can do if the owners of the servers who are serving my software tell me "before we can change this server's configuration we need approval from another office, it will be a few months until they can get back to us." (This is a hypothetical situation, for me, because I eventually got all my customers on HTTPS back around 2012 or so. There was some push…
Chrome 56 will mark HTTP pages with password fields as non-secure
291–300 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#292Earlier quoted context omitted.
This is false. Passwords are only as sensitive as all the data they access. Given that it's impossible for you to know what other data the user is protecting with the same password, you must assume all passwords are as sensitive as the most sensitive data a user might reasonably secure with that password. Do I wish things were different, and that everyone on earth used unique passwords for every site? Of course. But…
As someone who runs like a roleplaying site for like ten people (or several of them), I cannot be responsible for other people's bank passwords, nor should I be punished for daring to host websites without the huge added burden of cost of HTTPS. The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#293What should be done for routers and printers that are accessed by their IP address?
I suppose it really depends on your threat model. I think most offices will be fine with the warning. However, you could configure each device to only respond to the trusted IP address of a HTTPS proxy which at least lowers the attack surface for snooping.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#294Earlier quoted context omitted.
https://certbot.eff.org/ This. This this this. Automates everything so easily. I have helped someone personally deploy HTTPS for over a dozen sites and they all auto-renew without a hitch every 90 days. No Excuses. EFF did us a solid
Except the part where if you're using shared hosting and don't have the ability to run this software on your server, it's useless as I said.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#295I've got to say though, that this is a wee bit frustrating as a developer. SSL libraries are terrible, bug ridden, hard to work with, and there are huge sacrifices using a pass-through proxy to offer SSL. The brittleness of SSL libraries manifests not just in the form of security exploits, but also in the form of delaying the next generation of HTTP technology. Node doesn't support natively support HTTP/2 due to HTTP…
Out of curiosity, what are you referring to? Go has great HTTP/2 support, and is enabled by default since 1.6. It doesn't depend on OpenSSL either, which is a big bonus in my book
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#296Earlier quoted context omitted.
No, because the implication here is that the private key for these router0123.netgear.com type hostnames will be known to the consumer devices that are serving the pages, so they will be essentially public.
I think the idea is each device has its own FQDN, and gets its own certificates. Thus, breaking open your router only gets you "your" private key, they'd all be different. Buying one on eBay might be risky, but if you buy sketchy network hardware on eBay you're at risk in so many ways already... You can't do this with Let's Encrypt out of the box (unless you make small numbers bespoke devices) because of their Rate L…
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#297Earlier quoted context omitted.
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.
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?
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#298Earlier 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…
"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?
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#299Advancing HTTPS is one of a few good things Google made in the recent years. Thanks Google.
It's one of the few things they do that I can't find a reason they would be financially motivated to do so, other than increase developers' opinions about the company as a whole, which is a good thing for all.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#300Earlier 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.
Sounds to me like you can move to a better host that does provide LetsEncrypt and save money on your hosting costs to boot!