Kee Vault and Kee version 3.0

Kee Vault logo

I’m excited to announce a new Open Source password manager combining the best of the security of KeePass with the availability and usability of a modern web app. It works on any modern device or web browser, even when offline. After you ask Kee Vault to import your existing KeePass database you can access your Kee Vault from everywhere, with your changes and user preferences synced to each of your devices and browsers.

To make this improvement possible, we ask for a small regular contribution of £2 per month. I’m hopeful that enough of you will support this development to enable me to work full time on new features and improvements for both the new password manager and the existing browser extension.

If your existing KeePass database requires a key file to open it or contains large attachments you’ll need to remove them (reduce its size to under 10MB) before importing to Kee Vault. We will consider relaxing these limitations in future but need to see that there is a real need for it before making the substantial financial investments that would be required - please do let us know what your priorities are for future Kee Vault development.

Early access

We are currently preparing for a public beta launch but in the mean time, you can register for early access!

Early adopters will get a 2 month free trial before payment card details are required (normally 2 weeks). Plus, until the Premium subscription options are launched, all Supporters also get access to all newly developed features for those subscription tiers.

Kee 3.0 coming soon

Kee 3.0 will imminently be published to the Beta testing channel for Firefox users.

The main changes are:

  • Works with Kee Vault and KeePass

  • Reliability improvements

  • Google Chrome version is now stable (no longer beta)

  • New icon

Firefox users can join the beta testing channel.

New icon

The Kee icon hasn’t changed before - I wanted to retain the familiarity over the past decade even as the Firefox logo changed, I expanded the extension to work in Google Chrome and the name changed from KeeFox. With the launch of Kee Vault I think the time has come to give it a fresh modern look.

I wanted to create something with a cleaner appearance than the old logo and also ensure that the link between Kee Vault and the Kee browser extension is obvious. At the same time, I really wanted to retain a link to the history of the extension. I think that the use of an orange key brings this all together nicely and I’m delighted to be able to now show off all the hard work that went into this updated branding.

Kee logo

Let us know what you think!

Support for KeePass

Nothing is changing immediately with respect to how much time I can devote to the KeePassRPC plugin that links KeePass to Kee. I hope that enough people will subscribe to Kee Vault that I am able to devote more time to improving this more quickly in future.

While some Kee extension features are naturally suited to only one of KeePass or Kee Vault, I’m not intending to let the functionality drift apart by much more than is necessary.

Kee version 3 continues to work with KeePass and we have no plans to change this in future versions.

Company details

To enable the subscription payments, meet other practical legal and tax requirements and bring various developments together under a single brand, I’ve started a UK company called Kee Vault Ltd. I understand that this could cause concern among some users, especially those that have made any type of contribution to Kee in the past and although some concerns will be best discussed on an individual basis, I hope that the following official company declarations will help set the tone for what I’m trying to achieve:

Vision

Allow everyone on Earth to secure their digital world without giving up their privacy.

Mission

Enable easy and secure management of passwords while ensuring sensitive information never reaches us, or anyone except the information owner.

Values

  • People come first - without considering them, nothing can be secure.
  • Security throughout everything we do.
  • Profits utilised to achieve the mission, not line shareholder’s pockets.

Donations

The Kee Vault Supporter subscription at only £2 per month or £20 per year is now the preferred method for financial contributions - we get regular income and you get a valuable service in exchange. We will soon be de-emphasising the existing one-off donation feature to avoid confusion.

If you have recently made a donation of $10 USD or more and would like it to be applied as a credit to your Kee Vault subscription, please send a message using the feature within the Kee Vault app. Unfortunately this is not something we can offer for donations that are made from now on, or for those made more than one year ago.

Websites and domains

It can be a bit of a challenge to juggle similarly named entities and products into a coherent set of websites and domain names. After significant thought and planning, I decided to adjust the usage of these existing websites:

forum.kee.pm: This community forum will now be used for more than just discussion of the Kee and KeeFox browser add-on - some categorisation or layout changes are likely in the coming months to help make this change clearer for everyone.

www.kee.pm: This website still contains the same information as before regarding the Kee browser extension but that is now only a part of the content of that website - it’s overarching purpose is to serve as an information source for the Kee Vault Ltd company and the products and services we offer (obviously including the browser extension).

The most notable new domain name is keevault.pm. We use a new domain name in order to offer an additional layer of protection against malicious attacks on our websites: successful attacks against websites on the kee.pm domain are significantly less likely to lead to any problems for the password management app hosted on keevault.pm.

Future / Questions

Despite the length of this announcement (thanks for reading this far!) this is just scratching the surface of everything that’s going on as you read this - I’m putting into place all the pieces of a puzzle I’ve been working on full time for more than a year.

That means that there are bound to be questions that have not been answered yet and although I’ll not guarantee that I can respond individually, I will try to address whatever I can on this forum so please feel free to get involved in the new “Kee Vault” category.

1 Like

Good luck with your new venture Chris!

I think it would be very helpful for many of us that you also highlight the main advantages and differences between Kee Vault and other popular open source password managers such as Bitwarden in terms of features, compatibility with Keepass, cloud solutions, etc.

2 Likes

Will Kee Vaukt store the passwords locally (on my PC) or on cloud-servers on your side?
If the data is stored locally: will there be an option to sync it with my web-drive (OneDrive, Google Drive, etc)?

By the way: Kee Vault (https://keevault.pm/) looks like a 1:1 copy of KeeWeb (https://keeweb.info/)
Am I right?

Can you elaborate more somewhere on how Kee Vault will be different than KeePass and the many other KeePass derivatives? I regularly use KeePass on Windows and Linux, and sometimes KeePassX on Mac, so I’m not convinced cross-platform compatibility it a major issue…

1 Like

Having passwords available and synced across several devices sounds great and that is why MANY other password mangers offer it. The problem is when passwords are stored in the cloud a vulnerability is introduced that isn’t present when passwords are stored locally. I have brought this up to other password manager companies and I always get the response of how secure their system is by using the latest and greatest protection process. I am sure Target, Home depot, Apple Icloud services,… all felt the same way. This is why I ONLY store my passwords locally and why I have settled on key pass/vault as my web password management system.
How do you respond to the security threat introduced when passwords are stored offsite? There is a reason why the IT closet is locked, or should be.

The phrase-

also concerns me. I understand that servers to store offsite information cost money to maintain but I don’t want to use them in the first place. The last thing I want to do is put my credit card information out there where it doesn’t need to be in the first place. I understand wanting a one time donation to support software you use but I won’t be doing a subscription service.

Passwords stored offsite and paying monthly for it will get me to remove all of your software and look for a manager that stays local.

Security is always a matter of convince vs security and I draw my line at keeping passwords local and syncing myself during the yearly change.

4 Likes

Thanks for the initial feedback everyone. I’m still busy working through the source code upload process but wanted to address a few of your questions in the mean time…

With regards to comparisons to other Open Source alternatives, I’m not planning to maintain an ongoing information source for this at the moment - there are so many alternatives and variables/features that I’m not sure how to present this in an approachable and up-to-date fashion. So at least in the short term I’d prefer to focus on what Kee Vault does well and leave comparisons up to independent people. Once I’ve got things a bit more stable I might be able to come up with a partial comparison to get the ball rolling though.

Off the top of my head these points are probably relevant: Kee Vault…

  • Requires no installation (so you can get to your passwords anywhere without additional setup)
  • Works cross-platform
  • Is compatible with KeePass (so exporting is secure and older/rarer devices can still be used to a degree)
  • Can be edited offline

Most alternatives will offer one or more of these benefits but not all.

Both - obviously encrypted in both cases.

Around 1/4 - 1/3 of the Kee Vault code running in your browser is the same as KeeWeb. Much of the core visual structure is derived from KeeWeb so it probably looks much more similar than that on the surface.

Passwords are not stored off-site. They are all encrypted to the same standard as used in any KeePass-based service - you can verify this by looking at the source code, unlike most web password management systems.

@Landon_D I’m certainly not expecting to be able to convince someone that never puts credit card information into a browser to suddenly change their mind just for this service. I’m interested though about the difference you see between a one-off payment and the subscription. Is it that you don’t trust credit card companies like Stripe to keep your details safe for a prolonged period of time? Or you prefer to pay using a different payment method such as a cryptocurrency?

1 Like

For KeePass I have a local file on my PC and I can copy it to my phone.
I also can store it on Cloud Storages like OneDrive, Dropbox or Google Drive (if I wish).

Bitwarden stores the passwords on the Bitwarden servers and I agree that this is not very secure.
This is the reason why I am not using Bitwarden.

So can you please answer the following questions:

  • Where is the password vault stored (local machine or Kee Vault Servers)?
  • If it is stored locally: how does the sync to all my devices work (via Cloud Storages)?

Best regards

OLLI

1 Like

I hope that this isn’t the direction that you are shifting your focus. I already can access my passwords and have them synchronized across devices by using the Keepass format and my own secure private storage with various clients and Kee for Firefox.

I am sure, like myself, that many would NEVER put their keepass database into a shared storage / cloud system. It just defeats the entire purpose of using Keepass versus one of the many alternative password managing services.

3 Likes

I totally agree.
I would never put my Keepass database into external servers, no matter where they are.

Both.

Yes, the “Kee Vault servers” are essentially acting as a Cloud storage service in this regard.

I also understand the concerns of @smint and @snovak, and I’m sure they are not the only ones in the world with these concerns. If you have decided that you will never put the encrypted KeePass data anywhere other than a machine that you keep offline, I don’t expect to convince you to change that view. For the benefit of those following this thread I will reiterate that…

A) This approach is secure.

The KeePass data is encrypted using AES-256 and so far, despite over a decade of effort, no-one has found a way to break this encryption to get into a KeePass database.

Part of the reason for choosing KDBX (KeePass) as the storage format for Kee Vault is because it is established and well tested to hold up to offline decryption attacks. As with any cryptographic system, when one starts with the assumption that it’s component parts are secure, one can be confident that the final system is secure provided that those components are combined in a way that does not break any of the assumptions made by the individual components. Since KDBX is designed to be safe to share publicly, Kee Vault is secure even if a KDBX file were to be released to the public. Of course, good security is about layers of defences and you can see from the other information about Kee Vault and its source code that other layers of defence are also in place to further increase security.

If you really are able to keep your locally stored kdbx file hidden from the rest of the world forever then you are exceptional (some might also say an optimist). For a lot of people though, what matters more than keeping the encrypted data in a secret location is the security of the data itself, such that if (pessimists may say when) the data is exposed, there is no way to decrypt that data into a form that reveals the secrets (passwords) protected within. As explained above, KDBX has inherent protection against this risk.

Break KDBX encryption, AES, SHA-256, Argon, etc. and all bets are off. Although with that power, why the attacker would target your kdbx file over all the other government, military, financial and commercial information available to them is an interesting question. We all have different perspectives on the relative risks and benefits of any security system though and I completely respect that some people feel this is a realistic attack scenario that they must defend against by any means necessary. As I said, I’m not here to try to change that viewpoint.

B) Nothing is changing regarding Kee and KeePass except that if enough people have a different view to you and decide to support Kee Vault financially then you’ll benefit from some of the improvements to Kee that are paid for by those people.

I’m happy to continue discussing the security of the kdbx format and the protection that gives against decryption if/when the encrypted data falls into malicious hands - some of the theory around this risk, both technical and anthropological, is fascinating. That said, I can’t dedicate much more time to that topic in the short term and such discussions should probably be split off into a separate thread, or potentially onto the KeePass support forums. Feel free to do so if you wish.

I don’t like subscription services because they suck money forever. $5 per month for three years is $180. I would never pay $180 for a password manager. It takes effort and time to make a decent password manager and I don’t expect it to be free. A decent fee for a stable manger could be between $5 to $15 but definitely not $180. I use a local password manager that is several years old. I don’t need to keep paying for future development that I don’t need. It is encrypted locally only and the only way to steal my passwords is to take my hard drive and then crack my master password. If my hard drive ever gets stolen I can be bothered to reset all of my passwords.

How can I

If my encrypted password database is not stored somewhere other than my PC?
There should be an option to turn off this “convince” and never allow any form of my password database to be transmitted to any other device over the internet.

Personally, I’ve picked Keepass specifically because of the availability of the key file.

I make a fairly simple set of assumptions:
1.) Any password I can remember isn’t secure.
AND
2.) My database is unreadable without my password and the key file.

As such, I’m willing to put my database in the cloud, so long as I never put my key file in the cloud. I protect the key file digitally similar to how I would protect a real key physically. The password is only secondary protection for if someone steals my phone or my computer and gets access to the key file.

It sounds like, at least initially, local key files won’t be supported by Kee Vault. I’m curious, will the underlying architecture potentially support this in the future, or does the Kee Vault architecture rely on being able to unlock the Keepass database on the server side?

Good luck!

On the topic of my dislike of cloud storage of passwords I came across this feature in another program.

1Password also contains a few extra niceties you don’t get with other apps. If you don’t trust your passwords to the cloud, for example, 1Password offers the option to only sync your passwords between devices over Wi-Fi.

So it is not just me that doesn’t trust cloud storage. Instead of wifi syncing I would set it up to recognize my wired network.

And there is this-

If you’re the kind of person who doesn’t trust companies with your data and wants full control over everything, [KeePass] may be the option for you. It’s free, open source, extensible (so anyone can add features to the program), and if you want, it can work entirely offline with no cloud component. You can, however, sync your KeePass database with Dropbox or another cloud syncing service if you so choose.

but now you want to take away the option to not use cloud storage so -1 point.

I’ve not yet been able to come up with a good way to support key files that functions correctly on all devices and doesn’t frighten non-technical users but the architecture would support it - all KeePass database unlocking is client-side.

In the short term, I intend to add the ability to import a kdbx file that uses a key file but the key file would be thrown away rather than used as part of the master key for the new Kee Vault kdbx file.

Being able to sync with specific devices only is something I’ll be considering as a future feature, although I’m not sure if a blanket “white list” based on the local/WiFi network is possible. I’m also not currently planning to develop that feature as alternative to storing the kdbx file on the Kee Vault cloud but I’m not ruling that out forever.

The additional options that Kee Vault offers to you might not be to your preference but there are no options being taken away.

Right now keepass database is only stored local. If I can’t do that in a new version I lose that choice.

I am one of the IT Admins in the company I have been working at since 2012, and we use KeePass (With Kee/KeeBird) as our standard credentials storage and manager solution.

The use-case here is this:

  • All employees have their own KeePass DB in which to store their personal company credentials
  • All departments have a shared KeePass DB in which to store shared departmental credentials
  • Some departments have access to the KeePass DB of other departments
  • All KeePass DBs must be secured by a key as well as the Master Password
  • The KeePass DBs and keys are never to be stored on the same storage medium

Before we adopted KeePass as our standard the discussion was essentially between KeePass vs LastPass. In the end KeePass was chosen due to LastPass being a Cloud Service, and KeePass being locally stored. I won’t lie - it hasn’t been seamless using KeePass, especially with regards to browser and mail clients etc … let alone attempting to use it on mobile devices etc … Which is why for my private life I use LastPass, even though I really, really tried to have KeePass as a replacement it just never cut it - the usability took too long and was too much hassle.

I think the idea of KeeVault is really interesting, if not exciting. If this could be made as secure as current usage of KeePass then I see us being quite happy to financially support the endeavor.

As far as I understand, the KeePass DBs themselves would be stored on a server, and this would then enable the access of credentials stored in these KeePass DBs from any device. The DBs themselves are secure (or as secure as the Master Password is), so this would be similar to having a KeePass DB stored on GDrive, NextCloud or DropBox.

The concerns I can see arising from us are:

  • Where are these servers located? (At least the Country)
  • Is Two-Factor authentication still available?

And a question I have regarding usability: Will AutoFill work on mobile devices?

Thanks for communicating with us all and keeping us informed.
I look forward to the progress made with this new endeavor.

3 Likes

I can promise you after 5 years of using Keepass2, KP2A, Firefox plug-in KPRC, KEE v2+ and having been a part of Chris’ other projects as a beta tester and daily user, etc., there’s no way whatsoever that the fundamental principle–the quintessential, precedential & most desirable aspect–of Kee/Keepass et al, is the fact that USERS MAINTAIN FULL CONTROL OF THEIR PASSWORD DATABASE…nowhere in luckyrat’s code has there ever been any hint of a user’s confidential information being passed to developer’s infrastructure, nor a third party etc!

In fact, his realization and proper assessment of the security vulnerability that existed by passing user name and password via the original Firefox HTTP-based plug-in for Keepass2 is what led to the development of a much more secure method that RESISTED man-in-the-middle attacks, sniffing by keyloggers or tricky ass stuff like a rogue site or malware attempting to steal the uid & pass by cleverly timing a “invisible” change to the active tab / browser window just as KP2 was passing the (originally unencrypted yet obfuscated) uid & pw to the active Firefox tab.

I don’t mean to answer for Chris, but rather to offer my sincere belief @luckyrat and the open source code developed into the apps he has continually improved upon for the community as a whole. Imho, based on his vision, mission and customer 1st / never compromise approach to security that I’ve personally witnessed and enjoyed for years, you should NOT doubt his sincerity that this new project be based on the same SOUND, FOUNDATIONAL CONCEPT that is improved upon by leaps and bounds over time, in order to overcome obstacles or shortcomings in the parallel albeit older Kee offerings.

I have recommended his products to ALL of my friends, family members, as well as my retail customers & EVEN A FEW FOES for years…because FRANKLY, nobody deserves to be forced to be at the mercy of OS / browser zero-days, known crapware vulnerabilities, hacktivists/crackers, viruses/malware, keyloggers, or their crummy ISP, …nor the snoopy Feds…up to and including the NSA!

WHEN EVERYTHING WE DO IS BEING WATCHED & RECORDED BY SOMETHING /SOMEONE, somewhere… I’m eternally glad to have THIS one thing within my control and I know beyond a doubt that was / is the driving principle and focus behind luckyrat’s every effort.

Thanks for taking my comments into consideration and cheers!

1 Like

Thanks for breaking down your specific scenario(s) [enterprise & personal] so thoroughly and for restating your understanding of what KeeVault is purported to be doing behind the scenes as far as accessing a KeeDB Server to keep multiple devices synchronized.

I took for granted that this project would first and foremost NOT be holding my .kdbx / password vault remotely…outside of my control & vulnerable to a variety of attacks of which I could not reasonably foresee, nor adequately protect myself against., i.e., off-site /OUTCONUS server locations and how the data is passed to and from.

I’d surely hope that at a minimum 2FA was MANDATORY and I would welcome end to end fully encrypted VPN tunnel to pass any and all information to & from and Kee DB server, wherever it may be physically / geographically located. Your thoughts are appreciated!

Thanks for the information @eab

Being able to reach the same technical security level of a native process while working within the browser execution environment is probably not a realistic aim at least in the foreseeable future but I’m certainly aiming for Kee Vault to be the most secure browser-based password manager. Of course, if the usability of “more secure” native password managers puts people off using them, one can conclude that they are actually adding no security at all! Hence my view that for many people Kee Vault is actually the “more secure” solution :slight_smile:

I’m not focussing on businesses at least until the service is working well for most consumers but if you can make Kee Vault work in a small business in the mean time then that’s great. I’ll be interested to hear what pain points you come across so future development can be better targeted to the most urgent needs.

Yeah more-or-less, although most people’s cloud storage is probably not behind an extra 256bit private key, and some of these services might not have additional at-rest encryption like we do on the storage server (although this extra protection is not a provable part of the security model so you have to discount this if you don’t trust Kee Vault Ltd). I think the Open Source Kee Vault client stands on its own without needing to consider what happens on the server-side so if it makes it simpler, just think of it as the Kee Vault version of Dropbox/GDrive.

The privacy statement goes into more detail but essentially UK, EU and/or US. Currently UK, with some backups in the USA but I can’t promise that’ll be the exact configuration all the time - essentially it’s all subject to EU data protection laws though and that won’t substantially change unless to enable even stricter protections for the data we hold if such possibilities become feasible in future.

I’ve started a separate topic about 2FA since it’s probably a question that will come up again at some point and I don’t want everything of interest to become buried in this single thread since it’ll be a bit harder for people to find as time goes on.

Not yet. I guess it will be possible one day but it’s not something I’ve ever looked into in detail. The only way I know to do this is to get everyone to install native applications from app stores, marketplaces, etc. which puts the cost of the subscription up by at least a third - potentially too high a price for auto-fill but I’ll definitely give the idea some proper attention later (probably this year if I can afford it). In the mean time, copying the username and password across the mobile clipboard should be fine, at least on the latest devices.

Thanks for your input @usnbrendon :heart:

There’s certainly not going to be any confidential information leaving your machine and as you say, this can be verified in the source code now and forever.

I’ve already linked to the 2FA discussion above and welcome your input into that if you wish. Please feel free to open a new topic about VPNs, etc. too - I’d be interested to hear more details of what you’re thinking this feature would look like and how you see this increasing the security of the service (e.g. how does it differ from the HTTPS tunnel already in use?).

Another architecture question:
Are the user’s kee vault login password and the master password of the stored kdbx file the same?

If so, does this create an additional risk in that the (appropriately nonced and hashed) password database becomes an easier attack vector to get kdbx master passwords in the event of a server compromise?

(I think this question applies even if the server-side kdbx file uses a hash of the password and other server-side information as the kdbx password.)

Thanks!

1 Like