dani-garcia / vaultwarden

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
GNU Affero General Public License v3.0
38.47k stars 1.87k forks source link

Vault sync/export in case of no network access #826

Closed void-in closed 4 years ago

void-in commented 4 years ago

Subject of the issue

First of all thank you very much for this wonderful project. We are hosting our own Bitwarden_rs server in our data center. Just wanted to know is there any option to sync the vault on the client machines so that in case we don't have access to our data center bt machine, we can get the credentials through the locally synced vault on the client machine and then login into the server machines through console?

Your environment

I know about the rs_backup to periodically take the backup of the persistent data or the DB but what I want is to be able to sync the vault locally so that if the server is not accessible, we are still able to view the stored credentials.

Thank you very much.

Update: So I believe the above requirement could be fulfilled if we have some option to export the vault from the command line of the bitwarden_rs server (just like the one in the UI). Just wanted to know if there is any such functionality available now or in the pipeline.

tomuta commented 4 years ago

The whole idea of bitwarden is that your credentials are safe, even if someone were to be able to steal the server database. So, by design, you cannot export the credentials on the server side, as the server would have to know the password, which is never sent to it.

The only way to accomplish this would be an enhancement of the client(s).

A better approach would probably be mirroring the database (mysql lets you sync servers in real time), and running backup instances? You'd have to share the server key between them, though.

void-in commented 4 years ago

@tomuta Thank you very much for the response. Yes I totally understand where you are coming from. I was thinking about the way the vault is exported from the UI where it asks for the master password and then decrypts the credentials and export in plain.

Backup instances are good but our issue is we want to be able to recover the credentials from the vault by logging into the server through the console and still able to recover the credentials using the master password. Bitwarden has the option to export the vault from the command line using the master password https://github.com/bitwarden/help/blob/master/_articles/miscellaneous/cli.md#export so I was thinking if something like this is possible with bitwarden_rs as well.

tomuta commented 4 years ago

Well, we could write such a cli tool as well, but this again requires the user's master password, which they can change any time.

void-in commented 4 years ago

Master password shouldn't be a problem since the same activity can be done remotely through the desktop client connected to the server remotely. So having the option to do the same from the command line would really be helpful for the self hosted option in case one is unable to connect to the bitwarden_rs server because of connectivity issues.

fbartels commented 4 years ago

The cli client is using the same api as the web client and therefore works just the same also with bitwarden_rs.

I haven't tested the desktop client, but the chrome extension does cache your vault and can easily be queried while offline. the one thing you cannot do in that case is modifying or adding entries. And I do think that attachments are also only kept online.

mprasil commented 4 years ago

And I do think that attachments are also only kept online.

That's correct /api/sync does not sync attachments.

void-in commented 4 years ago

@fbartels Thank you so much. Indeed you are absolutely right. I should have tested it first. Not only the Chrome but the Native Windows Desktop client is also able to open the vault in a read only mode without requiring connecting to the server.

Also, the cli is compatible with bitwarden_rs just as it is with the bitwarden. Thanks once again to you and @tomuta for looking into this.