Feature Request - Kee should have the option to prevent the filling in or submitting of forms unless it can determine if the connection to the site is secure. It should at a minimum check the URL for the presence of the https:// URI scheme. Ideally, it would actually validate that the site has a valid certificate, that the certificate has not been revoked, and maybe even enforce specific protocols, key sizes, or encryption types.
Justification - The reason this is a critical feature is that if a site is not using a secure connection then submitting the form could expose authentication credentials, possibly even before the user has a chance to react. Even just filling in form fields could expose data as it could be read through client-side code (JavaScript).
Kee, like users, has no assurance that the site that is responding to the URL in the browser is actually the site that a user has chosen to share sensitive data from Keepass. If the site is spoofed, DNS hijacked, or a site that has a Cross Site Scripting vulnerability, Kee could expose sensitive data to an attacker without a user having any chance to interrupt or prevent it.
This is a Bad Thing ™ and why for years the security community has been trying to teach people to look for the “Green Lock” and other information that validates the site’s identity before sending any information. Kee is an application so it should actually be easier to have it do such checks automatically, even prior to making a request to Keepass for matching URLs.
Due to these issues, many organizations and users are simply not able to use the auto-fill and auto-submit features of Kee. Adding this feature would allow these helpful features to be used in a more secure manner that might fit within acceptable risks for users and organizations. It also would help to show that Kee is taking extra steps to protect and secure data stored in your Keepass DB.
Initial functionality could be to just check the URL scheme for the presence of https:// in it and a user could either require or not require it for filling in or submitting of forms. A simple yes, no control on the options page would probably suffice for form completion, while a Yes/No/Warn option would be best for form submission: Yes, would allow the form to be submitted, No would prevent it, and Warn would prompt the user with a confirmation Warning prior to actually submitting it.
Allow forms to be automatically completed (filled in) for insecure sites? [Yes/No control]
Allow forms to be automatically submitted for insecure sites? [Yes/No/Warn control]
If Firefox actually exposes more information about the type of transport we could get really specific and get high levels of confidence to decide on allowing sharing of information. I’ll admit that this level of control might be more than most people need or care about and those that care about it probably will have configured the browser to disallow the connection instead.
Something like this (sorry for bad ASCII art for controls) could be added to the options:
It also looks like Kee already supports having different settings per URL, so these controls should be allowed to be similarly setup for specific domains. That way you could leave it less secure for general use and more strict for specific domains (such as company domains, healthcare, financial, etc)
Thanks for the detailed suggestion. I’ll try to give this some more thought in the coming months but wanted to just jot down a few initial thoughts now to try to keep the discussion on track in the mean time.
As I mentioned elsewhere, I’m keen to explore what Kee can do to help shift people towards https. Historically we’ve not done all that much (just prioritising matches that have the correct scheme over those that don’t). That’s in line with other password managers, at least at the time of it being implemented - I’ve not revisited this for some time now.
While there are UX challenges and backwards compatibility issues to consider, I’d like to come up with a plan to improve security in this area, even if some parts of that plan are then deferred until the wiser industry has suitably evolved (e.g. HTTPS prevalence and browser UI changes). There’s been a lot of improvement across the web industry in the past year so I’m hopeful that we’re already in a place where Kee can take some meaningful action without adversely impacting users’ day-to-day experience.
Can you elaborate on why you think there should be different options for configuring auto-fill compared to auto-submit?
Regarding warnings presented to the user, what form do you suggest they should take? Bearing in mind that the only non-interactive notifications extensions are allowed to create are the system notifications (which in my recent user testing were seen by only 1 in 10 people - a UX failure affecting all extensions and lots of other software by the way, but this is another topic). In practice, any warning may be technically limited to being shown only after the user has clicked on the submit button themselves.
My main concern with the part of the idea that deals with any kind of certificate validation is that the browser will already block such sites by default so a user will have to manually add an exception for the site to even be loaded to the point that Kee gets to think about filling or submitting a form with access credentials. I’d need to be convinced that there is a strong reason that security will be improved by repeating the built-in browser certificate checks within Kee even after the user has already put the website into a browser whitelist.
As for the per-site configuration, we definitely need some level of control beyond a blanket yes/no/(warn?) option so this is a candidate for that. The other option to consider is making it a per-entry setting. At its simplest we might just say that if an entry has a URL that starts with HTTPS, it will only be inserted to a secure page; or perhaps vice-versa for URLs that start with HTTP (or have no scheme in their URL).