I hope me trying to push this on G+ and Twitter for years helped.
This was always my first install on a new Chrome.
https://chrome.google.com/webstore/detail/unsecure-login-not...
Chrome 56 will mark HTTP pages with password fields as non-secure
311–320 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#312Firefox 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.
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…
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#313It's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself. Currently DNSFilter and others Man in the Middle traffic destined for sites our customers have decided to block. This works great for http, but not https, as certificate warnings are presented. The standard work around is arguably less secure: adding a third-party C…
Removing insecure HTTP altogether is the road Google is taking. That should make this a non-issue.
How does removing HTTP solve the issue presented:
When actively interrupting an HTTPS connection as a network element, there is no way to provide information to the user about the reason for the interruption or steps the user could take to prevent the interruption.
This can be done with HTTP, where a filtering proxy could show a page 'our software thinks this page violates company policies, but click here to override or contact IT to fix', or see also captive portals.
Maybe the right answer is simply there's no reasonable way to handle this use case in a secure manner, but taking away an established use is a real issue.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#314Earlier 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!
Wouldn't putting someone (whose server experience level warrants shared hosting) in charge of a VPS create more security issues?
It's the only way to learn...
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#315Earlier quoted context omitted.
It has for me with the Firefox version of this, and based on my experience of it sofar, this is fine. For one, it's an obvious differentiator between my local copy and live, but secondly I also think local certs are something that we really need to find a way to make easier for devs to set up and test with.
Where do you see the issue? Creating a certificate that no one else has to trust seems pretty easy already.
I guess a part of this is inconsistency between development environments as well, but generally speaking, while not completely impossible, the dev user experience is just that bit more fiddly.
For a prod server, the process can be as simple as (Ubuntu/Apache being a common setup):
apt-get install letsencrypt && certbot --apache
Or more generally:
$PKGMGR install certbot && certbot certonly
For dev, you need to either select and install an SSL library, generate snakeoil certs and install them into each vhost you use, and thereafter go through every varying and occasionally unsurpassable browser warnings about unverified certs, OR - much, much more complex - install and maintain a boulder setup.
Given the above, most devs will continue to take the chrome://flags easy way out, which doesn't really allow proper testing of a HTTPS setup locally.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#316Earlier 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…
> 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.
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#317Earlier 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?
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?
But anyway, not like we have a choice right!
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#318Earlier 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?
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#319Earlier 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?
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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#320Earlier 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!
Wouldn't putting someone (whose server experience level warrants shared hosting) in charge of a VPS create more security issues?
Well I can configure a Linux vm for development I guess I could handle that.
Wouldn't these VPS come with a sensible default?