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. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend:
- 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 with it over post messages.
I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.
My experience with let's encrypt so far:
- the name of their tool was changed form "letsencrypt" to "certbot", breaking my cronjob
- for daemons that try to access the cert/key as non-privileged users, additional fiddling with permissions is necessary, which may even be overwritten on cert update if done incorrectly
- when the certs are renewed, daemons need to reload them. This means that ideally, you need to detect when a renewal actually happens (as opposed to an attempt), keep an up-to-date list of all daemons that use the certs and possibly completely restart them, dropping all existing connections (some daemons just don't support a live reload)
I'm not saying these problems are unsolvable, but may take way more than 5 minutes and I, for one, opted to renew my startcom certificate for another 3 years instead.
The cronjob correctly renewed the certificate at least once on multiple servers, with no issues whatsoever. I was also warned that the certificates were expiring via email, which I thought was awesome.
Your mileage might vary.
Wait really? When did you do this? I thought all certs signed by their root after sometime in October or November are all considered invalid due to their shenanigans with WoSign. Not so?
> Distrust certificates with a notBefore date after October 21, 2016
Just in time!
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.
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 back and it did take a long time and we had to be very persistent with some customers... But it was well worth it!)
We are talking about the world of corporate IT and pointy haired bosses. I don't implement a social network, or email, I don't accept payments - I make intraweb sites that non-technical corporate paperpushers use to do their job. They are only interested in getting their work done; they are happy when they can get their work done without scary warnings they don't understand. If my software is giving them errors they are going to believe that it's my software that's the problem, and that doesn't look good for us. And we have to field support calls and explain ourselves.
...Or we could put a quick and dirty stopgate in to avoid something that makes us look bad and we can't do anything about.
https://www.troyhunt.com/https-adoption-has-reached-the-tipp...
TL;DR: HTTPS is now workable and affordable.
This is entirely dependent on how your site is hosted. For some shared hosting platforms, it may not be possible at all.
It's only easy if you're using a Linux webserver. In IIS land it's a pain.
And if not, it's no big deal, users will just be informed that the page is not secure, which is true.
Don't like the message? Work to secure your damn website.
When companies like Google and Mozilla decided how to handle HTTPS, they decided based on their needs and their perception of everyone else's needs, like banks and major corporations. This led, IMHO, to a complete failure to recognize a lot of other uses for the Internet, and so their solutions fail to adequately account for them.
This has been coming for quite a long time. The time for excuses is over. If you think the safety of your users is "simply not worth it", well, I'd like to know what your websites are so I can block them at my firewall. I'm not saying this to be a dick, I'm saying this because this is an attitude of callous disregard on display, and it's downright odious given the modern security climate.
LE is not that hard to use, and I seriously question whether you can't make an API call once every 90 days per subdomain. The requirements have never been lower.
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
Of course, it works in Google's favor to make it unfeasible to maintain a website outside a cloud platform. It's amazing here people are so opposed to the democratization of the Internet, and so supportive of the death of it, over security provisions that will, in retrospect, be considered largely ineffective.
Say what you will, but pushing for passwords to be transmitted securely isn't Google fighting against the democratization of the Internet. They're doing that in other ways, sure, but promoting encryption isn't one of them.
So, right now, I have 24/7 American-based phone support (this is a must-have), 99.9% uptime guarantee, WHM/cPanel software licensing included, 60 GB disk space, 600 GB bandwidth included. By all means, if you have a VPS service that can offer all of this at less than $30 a month, I'd love to consider it. I haven't changed hosting providers in a while, but I haven't found a company capable of meeting the requirements.
Do I wish things were different, and that everyone on earth used unique passwords for every site? Of course. But I think you know that's never going to describe reality.
The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.
The top-level page also has to be served over HTTPS for the warning to not appear. (source https://developers.google.com/web/updates/2016/10/avoid-not-...)
There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling…
Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.
And the third thing: authenticity.
No-one has modified the page, for example to insert or change advertisements
This will mark pages as insecure that have a '<input type="password">' field on your page. If you don't have that, you are fine.
I don't know of any reasons to have a password field if it's not actually sensitive information that's being entered.
This is actually a Good Thing - with HTTPS-friendly CDN and/or Letsencrypt, rolling out sites that are secure-by-default is now easier and cheaper than ever before.
Right-click paste from my password manager, and it doesn't work. Thanks.
---
This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.
It's still a horrible idea, but it'd work.
Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.
For anyone who is wondering what these ways are, here are a couple:
1) Backspace is a crufty special case
2) What happens when someone highlights text in the input box and types over it?
So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about?
You certainly can't get away with just wiring keystrokes to a field.
Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?
For those wondering you can mask a normal text field in css input { -webkit-text-security: disc; }.
Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.
Good. I hope browsers autodetect these web font tricks and pop up similar warnings. I can't stand when some random website make thinks it can do a better job of credential security than major browser makers.
This is a Torvalds "don't break userspace" moment.
[1] https://xenforo.com/community/threads/let-tls-wait-paid-dele...
Pm - "why is this page insecure"
Developer - "chrome labels password fields as insecure over http"
Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure"
Developer - "But you didn't care when there was no encryption"
Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".
Sigh. Our industry in a nutshell.
https://www.bancomer.com/index.jsp
Click "Acceso a clientes" and write numbers.
Developer - "chrome labels password fields as insecure over http"
Pm - "what if it wasn't a password field"
Pm - "If its important enough to hide, its important enough to stop from being intercepted. Think social security numbers, PINs, tokens, drivers license numbers, etc. Why aren't we encrypting things that matter?"
Developer - "chrome labels password fields as insecure over http"
Pm - "what if it wasn't http?"
Developer - "..."
Pm - "put one of them modal over it"
Developer - "but then how will anyone..."
Pm - "we're switching to <completely different stack they heard about from someone in their uber last week>"
/me opens a sake bottle.
Developer - "chrome labels password fields as insecure over http"
Pm - "what if it wasn't a password field"