Kee Vault and Kee version 3.0

Project news
8

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
9

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
10

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

11

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.

12

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.

13

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!

14

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.

15

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.

16

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

17

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
18

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
19

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!

20

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?).

21

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
22

Yes.

It presents no security risk because:

  1. The master password is never directly used for accessing the kdbx file or the Kee Vault authentication server. Instead, two different and cryptographically unrelated 256 bit keys are created - one per the usual kdbx access process (Argon2) and one using PBKDF2 (SHA-256 500 iterations).
  2. The resulting Kee Vault authentication key is never sent to the authentication server - instead SRP is used to verify both the server and the client (user) are who they say they are.

This means that server-side compromise reveals only an SRP verifier. Breaking this (cryptographically close to impossible - no one has done a similar thing yet) reveals only a 256-bit secret key that is unrelated to the information needed to open the kdbx file. In that worst-case scenario of SRP being broken, any attacker would still need to brute force via the PBKDF2 protected secret key before a master password could be revealed.

Additionally, the secret key contains salts including your email address to protect against large-scale (untargeted) attacks. Since your email address is AES encrypted in the database that contains the SRP verifier, this further reduces the chances that a remote server compromise is a feasible attack vector. All this essentially combines to mean that a client-side attack is the only feasible risk in this regard, and no client-side attacker is going to find that breaking SHA-256 or brute forcing PBKDF2 is the easiest approach to take once the client is compromised.

23

Will this support the k-anonymity API for checking passwords against the “have I been pwned” database?

24

Probably at some point. Feel free to open a separate discussion about how you’d like that feature to work.

25

Kee v3.0 has now been submitted to the Firefox and Chrome stores!

As usual there’s no certainty about when they will actually appear or be pushed out as automatic updates to existing users but hopefully it will at least be sometime today. For the rest of the day I’ll be keeping an eye on this forum and working through a lot of text and image updates to the Firefox and Chrome store pages. In between that I’m working through a variety of improvements already planned for version 3.1 - as usual beta testers will be the first to get to try them out.

I’m now closing this thread so that doesn’t become a monster covering many different topics. If there are any conversations within that you would like to continue, please feel free to start a new more-specific topic. If there’s a post in this topic that you think should be extracted to a different topic just let me know and I’ll see what I can do.

To anyone that comes across this topic for the first time in the coming days, please do feel free to contribute to other topics in the new Kee Vault category or just post an “Uncategorised” topic if you want to talk about Kee version 3.0.