What will this feature do differently? many users are keepass user and by support kdbx format natively. it can integrate database between these app smoothly
What benefits will this feature bring? integrate between platforms easily
Remember to add a tag for each client application that will be affected
Related topics + references
Are there any related topics that may help explain the need and function of this feature?
Are there any references to this feature or function on other platforms that may be helpful?
.kdbx files are encrypted database files which cannot be read by any third parties (including Bitwarden). You have to open this file in Keepass, and then export your passwords in .csv or .xml format, which can be imported into Bitwarden.
Bitwarden uses end-to-end encryption. When importing your passwords, the Bitwarden app on your local computer encrypts the password file, then uploads it via a secure (SSL) connection, and stores it in fully encrypted form in the cloud. In the unlikely event that Bitwardenâs servers are compromised, your encrypted vault is still completely secure as long as you have chosen a strong Master Password.
If you are concerned about the security of exporting your passwords from Keepass, then the solution would be to export the plaintext file into a Veracrypt container, or onto a USB drive that you can reformat (or destroy) after you have completed the import process.
I do not understand what you are trying to say here.
Welcome @Jetrom to the community !
I think what you are trying to say is about interoperability between 2 different password managers so that their would be smooth transition from one password manager to another.
In the foss community , interoperability is often encouraged so that users are not locked into one service and can switch anytime to an alternative without a hiccup or loss of data.
In our case this could be used for creating a kdbx backup or importing from one.
Backing up your vault in something like a kdbx format would be beneficial for many. I personally keep my offline backups in kdbx format.
Currently you need to export the vault into a unencrypted csv and then import it into a kdbx format.The same is for imports.
I donât think the BW vault could natively use kdbx format as both of them handle the encryption keys differently.
But maybe work could be done for importing kdbx databse directly into bitwarden for smooth user transition
i hope it helps.
(kindly change your Feature request subject)
related requests -
@Gaurav Thank you for explaining further. If the goal of the feature request is to allow users of Keepass to easily switch to using Bitwarden, then the current import functionality should be sufficient. On the other hand, if by âinteroperabilityâ, you are envisioning the possibility of simultaneously using both Keepass and Bitwarden, and frequently synchronizing the vaults used by the two apps, then the current import functionality would probably be too cumbersome.
Perhaps somebody in the Bitwarden contributor community will see value in the request and take it upon themselves to develop import/export support for the .kdbx format. If not, your best bet to achieve interoperability would be to connect with contributors to one of the many Keepass projects and persuade them to implement functionality for exporting vaults in the form of a password-encrypted .json file, which can be imported using the Bitwarden CLI app; the code for creating a Bitwarden-compatible .json file that is encrypted using a user-supplied password is available on Github.
In either case, your goal of transferring vaults between the apps âwithout hiccup or loss of dataâ is not likely to come to fruition without major changes to the Bitwarden codebase. This is because Bitwarden currently has no mechanism for importing attachments or item modification dates, both of which may be contained in .kdbx files exported by Keepass.
P.S. I changed the topic title of this feature request from Tip for Bitwarden to Support KeePass Extensible Database (.kdbx) format. However, I agree that it can be merged with the older Feature Request you had found (paging @dh024 to do this).
