Hey, any update on this?
That would be awesome!
1 Like
If the application allowed exporting to stdout, then we could use generally available CLI tools (like GPG) to encrypt it ourselves. Seems the easiest thing to do.
You already can do this with the CLI using the “list” command.
It’s not the same thing. The list “list” command wouldn’t allow me to import the secrets back into the vault with a single command, like “export” does.
It’s the same JSON objects though. Would just need a little re-conditioning for importing it back in. I’ll see if I can add a stdout to the export command though.
@kspearrin When you do, please try to keep as many information from the input as possible.
Password history and creation time would come to mind. Both can currently not be imported afaik. In case of the creation time it’s more or less pedantic, but the password history can be important in some cases (for example a failed LDAP propagation suddently requiring you to have your old password at hand … or a not properly synced full disk encryption password on a MacBook within a corporate domain).
2 Likes
This is not good. I think maybe we need to start distinguishing exports from backups. Backups should be complete. All available data should be preserved.
The easiest type of backup dumps everything in its original stored format, changing it only enough to allow a proper restore. We don’t need csv or json backups, we just need backups that can be later restored.
1 Like
I agree, except that I want backups to be human readable and editable. But this topic is for encrypted export/backup/whateveryouwanttocallit.
Ideally, there will be 2 types of backups available:
- encrypted
- human readable/editable
I agree that backups should be complete, preserving all the data. With human readable/editable backups, the user can manually remove any unwanted data. Additionally, bitwarden could provide a GUI with checkboxes prior to performing the backup, to allow the user to specify what types of data to backup.
If it wasn’t for the fact that backups are currently human readable/editable, I would have had no idea that items in an organization are not backed up when the main account is backed up. Being able to manually read the backups saved me on that one.
2 Likes
At the moment I store the unencrypted .csv export in a WinZip file using AES-256.
As I’ve come to learn the strength of the encryption depends on:
- A strong password (length+entropy), and
- The implementation of AES in WinZip
Despite my research, I can’t find anything to indicate that the implementation in WinZip has been audited/verified.
Does anyone have n opinion on that? What about the strategy of encrypting the .csv using WinZip - is that a reasonably safe option?
Thanks.
And how long is your password for that then ?
1 Like
Between 20 to 40 characters.
1 Like
Did you evaluate the time it would take to decrypt it to have made a password higher to 20 char ? Or was it just to be safe ? Because to my knowledge, something superior to 11 with all ascii code activated is already taking much more time than a lifetime… or is it a specificity to winzip file ?
Whether the password is 11 characters or greater is probably not as material as the correct implementation of AES in WinZip, which is really the key issue.
And it’s that bad?
I have no idea what you mean - what’s bad?
The winzip implementation
1 Like
I think it might be nice but if I die I don’t think the goal of the export should be to export yet another encrypted thing. You want a pretty raw, cold storage backup of sorts and you need to have something as accessible as possible (that is, not encrypted and locked up in yet more layers of obscurity.) I would think someone could contribute it as a feature but I wouldn’t expect it to be something the dev should be concerned with. If anything, I could just export and then encrypt the file with some 3rd party encryption program.
1 Like
I think you may have misunderstood. I’m not stating that the implementation of AES in Winzip is bad - I’m simply asking if anyone is aware of how good it is/isn’t or know if their implementation has been audited.
Since exports of vaults are currently an unencrypted plain text file, a reasonably secure backup of this file might entail zipping and encrypting it in Winzip (or even 7Zip for that matter) …but only if you can be confident that the encryption algorithm has been correctly implemented.
How sorry @Col I thought that you had chosen such a big password because the implementation and the management of the Entropy was bad. Sorry to have misunderstood you:)