Kee keyfiles to login

Kee browser extension
1

Hi

Just switched from bitwarden to keepassxc

The firefox browser extension on bw is so much better. Kp doesn’t do wildcards and other frustrating bits

Kee vault browser extension is better than kpxc.

However 2 red flags come to mind

  1. Kee V doesn’t allow keyfiles. Can this be added back please

  2. 10 mb limit?

  3. Can we keep the database local only if we want to? That’s a request.

Thanks

2

Thanks for the feedback.

  1. I covered this a while ago in 2FA/MFA in Kee Vault - since then we’ve introduced biometric sign-in on mobile devices but the fundamentals behind the choice to avoid keyfiles in the master key are unchanged.

  2. That’s right. Typical Vault sizes are 100-1000 times lower than that. There’s room for many thousands of entries within that limit and even a lot of little file attachments. The password management storage format is not designed to work well with large files though so it’s not the right choice as a general purpose secure file storage solution.

  3. That’s not something we’re able to offer. The information below about the security considerations of syncing the database to our storage servers might help provide some additional context on this topic. You might already know some of it from your earlier experiences with keepassxc.

The Kee Vault data is encrypted in the KeePass (KDBX) storage format, using AES-256 and Argon2. So far, despite over a decade of effort, no-one has found a way to break this protection 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 well established and proven to hold up to offline decryption attacks. Since KDBX is designed to be safe to share publicly, Kee Vault is secure even if a synced KDBX file were to be released to the public. Of course, good security is about layers of defences and you can see from 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 passwords 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.

The one thing you can never see for any cloud service, even an Open Source one, is what really happens in that service with regards to enabling access to the encrypted data. However, since you can see that only the complete KDBX file is transferred from your device to our cloud, the potential risk in the worst-case is no greater than the risk posed by an offline attack (i.e. the protection from technologies such as Argon2 limit the rate at which an attacker can attempt to break into the encrypted data). As a matter of fact, we don’t provide any mechanism for an attacker to perform mass attempts to guess the password to your encrypted data but even if we were lying or mistaken about this claim, the inherent protection from the KDBX format would kick in at this point, making an attack futile.