[GH-ISSUE #376] Document security relevant implemenation aspects #217

New issue

Closed

opened 2026-03-03 01:26:52 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 01:26:52 +03:00

Owner

Originally created by @theduke on GitHub (Jan 30, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/376

Hey, awesome project!

It would be great to document some more security relevant aspects of the implementation.

Note: I neither know anything about the official implementation nor about the code of this crate, I've just glanced at the table layout.

Some questions:

I don't see any crypto dependencies. Is all en/decryption handled by the clients? If so, why do we even need to store a private key? ( I just saw the private_key column on the user table )
Are private keys encrypted at rest? It would be great to have the sqlite file not contain unencrypted private keys and limit the expore to a docker env var with the key encryption key so .
Are there any other security relevant aspects that one should consider before choosing/deploying this?

Originally created by @theduke on GitHub (Jan 30, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/376 Hey, awesome project! It would be great to document some more security relevant aspects of the implementation. Note: I neither know anything about the official implementation nor about the code of this crate, I've just glanced at the table layout. Some questions: * I don't see any crypto dependencies. Is all en/decryption handled by the clients? If so, why do we even need to store a private key? ( I just saw the private_key column on the user table ) * Are private keys encrypted at rest? It would be great to have the sqlite file not contain unencrypted private keys and limit the expore to a docker env var with the key encryption key so . * Are there any other security relevant aspects that one should consider before choosing/deploying this?

kerem closed this issue

2026-03-03 01:26:52 +03:00

kerem commented

2026-03-03 01:26:53 +03:00

Author

Owner

@dani-garcia commented on GitHub (Jan 30, 2019):

Pretty much everything is encrypted client-side, yes. That includes the users private keys, which get encrypted with a key derived from the master password, and the master password hash (which we hash again to store it, to be safe). The only unencrypted things in the database I can think of are the users emails and unique IDs.

As that part is mostly done client-side, we don't have any documentation, but the bitwarden_ruby project has a nice API doc that you can check here. I don't know how updated it is anymore (attachments got individual encryption keys recently), but the basic crypto is explained there pretty well.

It might be a good idea to deploy the server behind a proxy, that way you can get websocket notifications, and you can configure other features like rate limiting, allowing only certain IPs to connect to the admin panel, etc. You might want to also use Fail2Ban to block brute force login attempts.

@dani-garcia commented on GitHub (Jan 30, 2019): Pretty much everything is encrypted client-side, yes. That includes the users private keys, which get encrypted with a key derived from the master password, and the master password hash (which we hash again to store it, to be safe). The only unencrypted things in the database I can think of are the users emails and unique IDs. As that part is mostly done client-side, we don't have any documentation, but the bitwarden_ruby project has a nice API doc that you can check [here](https://github.com/jcs/rubywarden/blob/master/API.md). I don't know how updated it is anymore (attachments got individual encryption keys recently), but the basic crypto is explained there pretty well. It might be a good idea to deploy the server behind a proxy, that way you can get websocket notifications, and you can configure other features like rate limiting, allowing only certain IPs to connect to the admin panel, etc. You might want to also use Fail2Ban to block brute force login attempts.

kerem commented

2026-03-03 01:26:53 +03:00

Author

Owner

@theduke commented on GitHub (Jan 30, 2019):

Thanks for the info, this pretty much alleviates all my potential concerns.

Would probably be good to add a short version of this info to the README.

@theduke commented on GitHub (Jan 30, 2019): Thanks for the info, this pretty much alleviates all my potential concerns. Would probably be good to add a short version of this info to the README.

kerem commented

2026-03-03 01:26:53 +03:00

Author

Owner

@pdarcos commented on GitHub (Feb 21, 2019):

I agree with @theduke
Awesome project and we should document the security model as best as possible.

To that end I highly recommend reading the Cure53 audit report https://cdn.bitwarden.net/misc/Bitwarden%20Security%20Assessment%20Report.pdf

Also Kyle's blog post has a good summary of the findings https://blog.bitwarden.com/bitwarden-completes-third-party-security-audit-c1cc81b6d33

@pdarcos commented on GitHub (Feb 21, 2019): I agree with @theduke Awesome project and we should document the security model as best as possible. To that end I highly recommend reading the Cure53 audit report https://cdn.bitwarden.net/misc/Bitwarden%20Security%20Assessment%20Report.pdf Also Kyle's blog post has a good summary of the findings https://blog.bitwarden.com/bitwarden-completes-third-party-security-audit-c1cc81b6d33

kerem referenced this issue

2026-03-03 08:36:14 +03:00

[PR #217] [MERGED] Device::save() should return QueryResult instead of bool #2668