mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-01 11:19:52 +03:00
Question: How much (if any) of the upstream bitwarden audit is applicable to this codebase? #153
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Algebro7 on GitHub (Dec 10, 2018).
Hey, new user here, and I apologize for all the issue threads and comments! I am looking at bitwarden to move away from keepass to facilitate syncing across devices and sharing, but keeping my passwords on a server is fairly concerning to me, and I'm particularly nervous about using an unofficial rewrite. I have played around a little with rust and understand that it should mitigate memory corruption vulnerabilities but I'm concerned about the possibility of logic bugs in the web interface and what kind of attack surface that could present.
I know the official bitwarden server implementation has been audited, but I was curious how much of the audit would apply to the bitwarden_rs codebase. It seems like pretty much none of it would since it's pretty much a full rewrite, although I haven't really looked at the code or read the report closely. Do the maintainers have any thoughts on this?
@dani-garcia commented on GitHub (Dec 10, 2018):
Well, most of the functionality is implemented in the clients, and everything important is encrypted before it reaches the server. You can look thorugh the list of issues reported in the audit, and you'll see that only a very small amount of them are related to the service backend.
This means that in the end, even if an exploit gave direct access to the database to a malicious user, as long as they don't have the encryption keys, the information that could be extracted is quite small.
That doesn't mean this codebase is perfectly secure, of course, and I'd welcome more experienced users to review the code.
@Algebro7 commented on GitHub (Dec 10, 2018):
Thanks, that was my understanding as well. The only real attack vector I can think of would be if the attacker were to compromise the server, they could modify the JavaScript code being sent from the web vault and theoretically use that to steal secret keys. Does this sound feasible or is there some protection against that?
I also haven't looked at the desktop client codebases but I believe they use electron and I'm not sure how reliant they are on JavaScript being served from the backend. I'm guessing they aren't since that's what Signal uses. It's also not possible to only use the clients because there is a decent amount of important functionality that is only accessible in the web UI currently.
@mprasil commented on GitHub (Dec 10, 2018):
The clients don't need javascript at all. In fact you can turn that part (the Vault interface) off completely by setting the
WEB_VAULT_ENABLED=false. You should be still able to do all the tasks with desktop apps which are essentially a packaged version of web interface.@Algebro7 commented on GitHub (Dec 10, 2018):
Unfortunately there is some functionality that requires the web UI as far as I can tell, such as adding new users, managing collections,
and adding new entries to collections,all of which I would argue are pretty vital for bitwarden's role of facilitating password sharing in organizations/groups. Those are all upstream issues though and hopefully they will be added in the future.@dani-garcia commented on GitHub (Dec 10, 2018):
All the clients share common code (maybe except mobile?) but only the web vault uses the scripts sent from the server, the rest use local code.
If the server is compromised, an attacker could just replace the bitwarden_rs executable for a different one, so I don't think it makes sense to protect the web vault from being modified.
Another possible similar attack would be a MITM, but you can protect yourself using HTTPS.
@Algebro7 commented on GitHub (Dec 10, 2018):
Agreed, I don't think there's anything you can really do to mitigate that except for adding all functionality into the thick clients and disabling the web vault. Unfortunately I don't feel like this is a huge priority for upstream after reading through their issue threads.
@dani-garcia commented on GitHub (Dec 13, 2018):
I think this isssue is settled now, so I'll close it.