So Kee is trustworthy... but how can I be sure?

[Larch35]

I’m going to say right up front that this is a genuine query, and is in no way meant to be accusatory or antagonistic (unlike some comments one might see on forums such as this!). Also, I apologise in advance if it sounds a bit naive or oversimplistic, but that’s kind of why I’m asking, as I’m not that well-versed in the world of software security.

With that out of the way - here goes…

I’ve been using KeePass for a fair while, but would like to make it easier to use - a bit more like Lastpass (with its browser extension), but preferably sticking with KeePass so that a) I don’t have the hassle of switching products, b) I don’t need to entrust my logins to a closed-source, commercial product, and c) I can keep my current ability to sync my vault over a cloud service but also back it up locally, and keep a version history of the database (not sure if that’s even possible with cloud solutions like Lastpass).

Therefore, when I did some poking around and found Kee, I was reasonably encouraged, as the screenshots make it look like the kind of thing I’m after, and it might (?) address the fact that I find the KeePass global hotkey doesn’t always work.

HOWEVER… I have to admit that when I went to install the browser extension, the following stopped me in my tracks:

This add-on can:
Access your data for all web sites
Read and modify privacy settings
[etc]

Likewise, when having to install a KeePass plugin and then authorise access to this third-party software… well, it just makes me nervous when I have a lot of sensitive, personal data stored away in my KeePass file, and of course if the data were to be stolen, it would be of incalculably greater potential damage than a data breach with just one service provider.

I have no doubt that these permissions are unavoidable in order for the Kee extension to work, but it still involves placing an awful lot of trust in the product/developer. My understanding is that it’s open-source software just like KeePass itself, but whereas the latter has had a great deal of attention over a long period (i.e. clever people crawling all over it looking for vulnerabilities), I just don’t know if the same can be said of Kee (& Kee Vault). It’s one thing to say this is open-source, so could be thoroughly checked over by anyone, and quite another thing to say that has actually happened and there are audit details to prove it.

So my query boils down to this. As an end user / lay person without a background in software, IT security etc - (how) can I be reasonably sure that this application is to be trusted with my most confidential of personal data (i.e. password database but also browsing data), and won’t (inadvertently or otherwise) upload it somewhere or otherwise expose it somehow to a third party?

[luckyrat]

Thanks for your question. Rest assured that I did not take it as accusatory or antagonistic.

The short answer is that as with any software, if you don’t have the time, inclination and expertise to inspect the software yourself, you have to place your trust somewhere. Personally, I would typically trust the wider community of open source contributors and reviewers more than a closed-source company product but a lot of people place their full trust in companies like Facebook and Google so everyone has different opinions.

The longer answer is probably best read in conjunction with the existing page about this topic (if you haven’t already done this): Open Source | Kee Vault Ltd

c) I can keep my current ability to sync my vault over a cloud service but also back it up locally

Yes, Kee Vault does this, although currently the local back up process is manual. I’m interested in feedback as to whether it would be worthwhile developing an automatic solution so do let me know if you go down this route and then find that this would be beneficial in future.

it might (?) address the fact that I find the KeePass global hotkey doesn’t always work.

Kee doesn’t interact with the global hotkey at all. It can’t automatically fill 100% of sign-in forms but it works for the vast majority so you should find it’s a big improvement overall.

I have no doubt that these permissions are unavoidable in order for the Kee extension to work, but it still involves placing an awful lot of trust in the product/developer

Yeah, browser extensions historically had full access to everything in your browser and although this situation has been improved in recent years, there is still room for them to make the permissions more granular. That said, and I say this in full knowledge that there are exceptions to this rule (particularly in business environments), full access to the web browser is typically of a lower concern than full access to the password database. So in the case of password management software, I’m not sure the relatively extensive permissions required compared to simpler browser extensions should be a huge worry.

I just don’t know if the same can be said of Kee (& Kee Vault). It’s one thing to say this is open-source, so could be thoroughly checked over by anyone, and quite another thing to say that has actually happened and there are audit details to prove it.

KeePass has certainly had more attention (funding) for security audits than any of the software I’ve released. Both KeePassRPC and Kee Vault benefit from this attention because we can be confident that the underlying method for protecting (encrypting) the data in your database/vault is secure. They can’t claim an independent person has verified there are no malicious backdoors, etc. although neither can a thorough security audit unless it is repeated with each release (they never are).

Many of the components that are unique to Kee Vault, Kee and KeePassRPC have also had many years of attention from others with security knowledge. I’m always careful to vet all code that gets included in all of this software and keep dependencies upon 3rd party code to a minimum, all of which helps to reduce the risk of bugs being introduced.

There is a lot more detail around the security of Kee, Kee Vault and KeePassRPC on this forum, although it may not all be written in an approachable manner for a lay person. If there’s any specific questions you can’t find the answer to, please let me know and I’ll try to help.

Likewise, when having to install a KeePass plugin and then authorise access to this third-party software

The nature of KeePass (and the underlying technology it’s built on) is such that it’s not possible to enable granular permissions for individual plugins. So again you have to place your trust in someone other than Dominik (creator of KeePass) - in this case, me. If you look around you should be able to find indications that people have been monitoring the behaviour of the KeePassRPC plugin for a long time - detecting things such as the connection to a web server to download the list of current public suffixes for domain names. Depending on your level of paranoia, this may be sufficient indication that existing or future bad behaviour will be noticed and queried.

On the topic of security flaws or backdoors being introduced after the most recent point that someone reviewed the source code or behaviour of the software, there are a few mitigating factors:

For Kee, Mozilla reviews the source code of each submission for malicious behaviour and the latest version of the browser extension can be inspected once downloaded - thus any deviation from the public source code can be fairly easily spotted.

For Kee Vault, automated systems convert the public source code into the application that gets delivered to your browser so again, multiple systems would need to be compromised in order for this to become a valid risk (and in doing so, this would be visible publicly). There’s still more to do in this area and I’m really looking forward to some forthcoming web technologies that will allow Kee Vault to offer a provable chain of trust right back to the source code in a way that is useful for non technical people.

For KeePassRPC, there’s not a huge amount that can be done to verify the integrity of the plgx file beyond trusting that someone other than me has built the file from the source code and verified that the output is the same as the one I have added to the GitHub release. Unfortunately the method of creating a plgx is complex enough that there aren’t any truly independent services that can offer automatic verification but it’s something I always keep an eye on in case the situation improves in future.

[Larch35]

Thank you for taking the time to reply in detail (which in itself is usually a good sign ). Having now read your ‘open-source’ page (thanks for the link), and also the ‘extension-permissions’ page (nice touch - I wish more app developers would do that), I also find it encouraging that you go to some lengths to address potential users’ security concerns proactively (might even say enthusiastically!), rather than taking their trust for granted. So - unless you’re some kind of evil genius with an elaborate and audacious double-bluff strategy - it’s all good reassurance!

Just to explain my point regarding the local backup - my current approach is to sync my database file (like any other file) to my cloud storage service via a desktop client, but I also have a local routine that takes a snapshot copy of the database periodically and stores that away, just in case of file corruption, user error or whatever - I want that security of being able to access a previous version of my database if a problem occurs. That’s one reason I’m sticking with KeePass rather than moving to something like Lastpass or Bitwarden, as I get the impression it would be difficult at best to replicate that arrangement.

I take your point regarding the relative concern of password database breach vs full access to the web browser, but the thought I didn’t relish was the idea that a malicious browser extension could potentially sit there in the background feeding browsing activity and/or submitted form data to some server over goodness knows what period of time, and “Access your data for all websites” sounds to the lay person like it might pose exactly that risk, but I suppose this is again where the open source nature should (theoretically, at least) provide some degree of protection, presumably along with the Mozilla review process. Likewise for “Read and modify privacy settings”.

Anyway, thanks for humouring my paranoia and also educating me a little (not least about the existence of Kerckhoffs’s principle… TIL!).