Browser: Thoughts on information loss and "trash" system...

[lainy]

Ideally there is no way a compromised server can harm you. From my reading of the browser extension code, in the unlikely event of a server compromise, an attacker could delete the vaults, or delete random entries in vaults. On next sync, the clients would replace their local copy with one that may be missing entries or empty altogether. No information would be leaked, but information would be lost.

This got me wondering how to mitigate such an attack.

Perhaps the easiest solution is to just keep the old vault (or do a diff and keep the deleted entries) in a "trash" area for a period of time. The UX for recovering a deleted entry or entries is probably the hardest part of this solution, but it has the benefit that it also solves accidental deletion, not just a compromise/attack.

Another possibility might be to authenticate (MAC) the current state of the vault somehow, although this may be tricky. For example, if you enable encrypt-then-MAC on the encrypted fields in all the objects, then you could MAC all the MACs (yo dawg...) and use that MAC-of-MACs to authenticate the state of the vault. The attacker would not be able to fake this "super MAC," and so you could just check that before swapping the remote vault over the local one. IMHO there's a pretty serious UX penalty if it false positives though, so any solution that authenticates the vault as a whole would definitely need to be careful about atomic changes to the database. Maybe the "super MAC" could be added to the -Request API objects, so a valid one is always pushed with every update?

I have not looked at the server-side code, so forgive me if I've missed some mitigations there such as a thorough backup plan. Still, it seems valuable to have a "trash" system in place.

[kspearrin]

It sounds like what you are suggesting is a checksum of the whole vault. I'm not really sure how this "protects" you from the situation described. How would the application know the difference between someone deleting things from your vault on the server vs deleting entries from another application? The checksums would be different in both cases.

Creating a trash based system is planned for the future which will help protect against accidental deleting and such, however, again that wouldn't help you if someone compromised the server and deleted data outside of the application code.

We have significant measures in place to prevent data loss from the core system database. This doesn't come from any of the code you see in the application, but rather from our cloud infrastructure. There are always 3 copies of the database available at all times (updated real time). SQL Server also has a translation log which allows us to point-in-time restore the database (to the second) for the past 30 days. So in the case of any data loss, we can always restore to a previous state. Again, these are all things we get "for free" by way of using managed cloud services rather than rolling our own infrastructure. You can read more here: https://azure.microsoft.com/en-us/services/sql-database/

[lainy]

Hm.. Well, I was proposing an authenticated checksum (HMAC) to be keyed off your encryption key, for example, so it could not be forged. The idea would be any time an update is pushed, the update request would carry with it the recomputed HMAC. But thinking about it more, I see that it would be really annoying to maintain consistent state across all clients in that scenario. Scratch that.

For what it's worth, trash system would solve the same problem if deletions that occur _as a result of a sync_ are also placed in a local trash area.

That said, it is good to hear that there are excellent measures in place on the cloud side to ensure data integrity, including historical data recovery 👍

[kspearrin]

The trash would be maintained on the server and likely only available in the web vault for restoring. So anything being synced would be non-trash items.

[kspearrin]

We are moving away from tracking Bitwarden feature requests like this one as GitHub issues. We have created a Bitwarden Community Forum which has a section for submitting, voting for, and discussing product feature requests. Please sign up on our forums if you want to continue contributing to feature requests.

Since this was a popular feature request we have already re-created it on the forums and linked back to this GitHub issue for reference. You can vote for this feature request there if you'd like.

https://community.bitwarden.com/t/soft-delete-items-to-trash/32

This issue will now be closed. Thanks!