What if the submits to an https page but the page is served up on an http page? The form submission will be secure, correct? Will Chrome still mark as insecure?
Chrome 56 will mark HTTP pages with password fields as non-secure
111–120 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#112Earlier quoted context omitted.
Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Loo…
you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low ...
I've noticed a lot of sites default to "show password" with a toggle so it wouldn't be insane to think they'd opt for plaintext the whole way.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#113Earlier quoted context omitted.
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.
google competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free? sorry to say, but https is not an altruistic move by google.
I can understand why they would want to convince everyone to use HTTPS to restrict access of your data from their competitors, but it limits the data they can collect as well. HTTPS has stricter cross domain policies so their ads would gather less information and their Fiber ISP would no longer be able to collect data by tapping connections. But on average, I think you're right that HTTPS would restrict more of your data to Verizon etc than to Google.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#114Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#115> A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS
Well OBVIOUSLY when the traffic is increasingly going to the same top ten sites like Faceboo, Twitter and Co.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#116Earlier quoted context omitted.
A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate…
Honestly, why would you do any of those things, now that installing a certificate takes 5 minutes and is free, with Let's Encrypt? I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.
If the only thing you host is a small blog without ads on a server that you have complete control over and spun up last month or something, sure it's 5 minutes.
In the real world, for many commercial operations, and especially for legacy code, there can be significant hurdles. For example, it took the NY Times 2 years to move to HTTPS, significantly more than 5 minutes, and they haven't even migrated 100% yet. https://www.thesslstore.com/blog/new-york-times-moves-websit...
Troy Hunt, a security expert, wrote about this topic a year and a half ago, and explained why, at the time he wrote it, his site wasnt HTTPS. http://www.troyhunt.com/were-struggling-to-get-traction-with... (this was before let's Encryt)
>unless you’re reading this in the future, you’re reading it on my blog over an insecure connection. That wasn’t such a big deal in 2009 when I started it, but it is now and there’s nothing I can do about it without investing some serious effort and dollars. I run on Google’s Blogger service which ironically given their earlier mentioned push to SSL, does not support it. Whilst Google doesn’t give me a means of directly serving content over SSL, I could always follow my own advice and wrap CloudFlare’s free service around it, but that won’t work unless I update the source of every single image I’ve ever added to almost 400 existing blog posts… and there’s no find and replace feature. This is the joy of SaaS – it’s super easy to manage and good at what it’s specifically designed to do, but try and step outside of that and, well, you’re screwed.
Another real world example, that I've encountered - your software is an intraweb site running on your customer's server and you have to play by their rules and policies on what your customers can put on their servers and when. And it's on exactly nobody's priority list.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#117Countdown until a JS extension that takes a normal field and uses • characters to make it look like a password field without tripping Chrome's detector...
Can we just ban inputs being manipulated on input? It's really annoying for custom implemented types like phone numbers that do the '(___) ___-____'. Half the time it seems they break if you mess up.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#118What if the submits to an https page but the page is served up on an http page? The form submission will be secure, correct? Will Chrome still mark as insecure?
The form submission is only half the issue. If the http page gets compromised the malicious party could simply read the contents of the password input.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#119I hope they do this for CC numbers too, because I know of a website I had to use that passed your Name, address, CC number, CC exp, amount; the whole shebang over plain ol' http to do a payment shudder .
Honest question, who is in a position to tap your connection such that this becomes a serious security concern? IT staff at your company? The admins at your ISP? The NSA? I'm assuming that public wifi has session-specific encryption keys. I don't see these as the kinds of concerns that would warrant the kind of panic that some people seem to show over HTTP.
> who is in a position to tap your connection such that this becomes a serious security concern?
When you use HTTP everything is sent in plain text. This means...
- Anyone on the same network as you can see all of your traffic. This includes company networks, coffee shop wifi, your house, the library; any place that has a WiFi network. Caveat: it's possible to use network isolation to hide your traffic but this is crazy rare to see and typically is done to isolate networks, not individual traffic.
- Your ISP can see and log everything sent over HTTP.
- Anyone at the router level that your traffic passes through. Your traffic makes a lot of hopes over various routers on the internet before making it to your final destination.
Overall it's a terrible idea for anything that needs to be sent securely.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#120Earlier 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…
Why do you have a password field on a http site?
Like every other person who started a forum some years ago or a wordpress blog you mean?
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.