Currently it is possible to delete a Bitwarden account without knowing the account master password, you only need access to the account email to click a link. This could allow for malicious account deletion leading to a user losing access to their vault (and all passwords).
If account deletion is requested without entering the master password the account should not be deleted immediately, instead:
– Mark account for deletion.
– Send user email that account was marked for deletion, with details on how to stop account deletion.
– Log user out of all active sessions.
– On next login, display message that account is marked for deletion in (30/60) days and details to stop deletion and restore account.
There is a legitimate use case for this feature. You may have forgotten your password or lost access to your 2FA and want to create a new account to start over.
However if you accidentally leave your email logged in, or briefly walk away and leave your PC unlocked, or someone gets a hold of your unlocked phone for a moment they could permanently delete your account which is why I’m proposing that the deletion be delayed and reversible.
The intent of this feature is to address the fact that while your Bitwarden account may be secure, your email account might not be, and a malicious attacker may be able to horribly disrupt your Bitwarden account even if they cannot access the contents.
An alternative is to have the ability to recover your deleted vault within a certain time-frame if you still know the master password.
What will this feature do differently?
An option to add a configurable delay to account recovery
Optionally long enough that a you won’t be in for a surprise at the end of a vacation, crazy week, extended service outage, etc
Display a warning to all sessions that a recovery or delete request has been issues
An option to dismiss the request
And possibly dismiss all future requests for some timeframe
Possibly limited to some upper bound, long enough to give the real account owner enough time to secure their email or change addresses
What benefits will this feature bring?
Protection from denial of service from a compromised email account/address
I came here to start a new feature request after a thread on the subreddit, but now I see that this request already exists.
This is the post I was about to submit:
When deleting an account without entering the master password (Bitwarden Web Vault), I would like to be able to specify a time delay and have the ability to cancel the action somehow.
Similar to the way that emergency access works with a trusted emergency contact, I would like to be able to specify (ahead of time) a specified period of time before account deletion would take place when initiated via this method.
I’m uncomfortable with the idea that someone could maliciously delete my whole Bitwarden account just by getting access to my unlocked email for 15 seconds.
Hopefully this would be easy to implement since some of the code can be borrowed from emergency access.
I’d be ok with pretty much any implementation, so whatever you think is best and is easiest to code. My initial idea was that clicking the link in the email would deauthorize all sessions and then any successful login before the specified time period would cancel the deletion.
I have no votes left, but I’d like to +1 this idea. My Bitwarden vault is very precious, and yes while I have backups I think an optional user-determined time delay for the account deletion by email feature would be brilliant peace of mind.
As of now if somebody compromised my email addressed used for Bitwarden they couldn’t access my passwords but they can delete my entire account within a couple of clicks forcing me to reset all passwords, reset all server logins and any personal notes i had would be impossible to retrieve please allow us to verify it is the owner attempting to delete their account
I am somewhat new to Bitwarden (I paid for the premium version to support the development/open source). I did some research/comparison before purchasing and this issue is literally the only concern I have from going “All-In” on Bitwarden. I’m a little disappointed to see this feature only has ~20 upvotes.
Would someone (@Peter_H) mind providing a little more detail on the “backup” workaround for this? Would a backup to my local device basically allow me to view all my data (username/pws)? And even in the rare event that someone maliciously deleted my account via my account email, my local backup would not be deleted and still accessible for as long as the backup exists on my local device?
The simple answer: I just export the vault every weekend.
The more detailed answer: I boot into a separate Windows installation that is making use of Bitlocker, I then export my data from the vault, pack it into a password-protected file and store it somewhere “different”.
To state the obvious: The issue raised here is an important security issue. Part of security is Availability, so if an attacker can too easily delete a Bitwarden account (thus making it completely unavailable), that is a security issue. In the case here, if an attacker can take over a user’s email account, they can delete the user’s Bitwarden vault. If the user hasn’t backed up their vault’s credentials elsewhere or, say, is traveling and away from the backup, this would be a serious problem for the user.
I like the solution proposed by dh024 on 2022-04-04, with one change: I’d burn the behavior he described into the Bitwarden code instead of making it configurable.
Delaying the deletion is not a security measure, even if you might consider it an availability / convenience measure.
From a pure security standpoint, when I ask bitwarden to delete an account I want the account to be gone.
What if I had only one phone accessing bitwarden and that device is stolen. Along with it I lost my bitwarden password (maybe I had it stashed in a local notepad application which is no longer accessible to me after the phone is gone). I also suspect the phone may be in someone else’s hands so I want to start locking things down as quickly as possible. I have no option to change the bitwarden password because I can’t get into the bitwarden account to do that. The only option is delete the account by email. Any delay on that request is a security impediment.
PS - even though I lost access to my bitwarden password, I might still have access to a bitwarden backup database if I had stashed a backup somewhere… but of course the bitwarden master password itself typically wouldn’t be be stored in the bitwarden database backup (there’s no immediately obvious value in storing the bwr master password within the bw database, outside of this particular scenario). Having that backup available means there is no downside to deleting my bitwarden account, but of course I still want it done quickly for security.
IMO @bw-tinkerer’s scenario of lost phone + lost master password is not a special scenario to plan for. If you forget your master password, you have not set up emergency access, and you haven’t configured BitWarden securely on your devices, you should expect bad things to happen.
The principle of prudent preparedness cuts both ways. You should have a backup copy of your bitwarden database (not just for this scenario but many others like when the bitwarden server goes down) in which case having your account deleted is not an unrecoverable problem. If you haven’t done that, then maybe you should expect bad things to happen.
But in either direction, we don’t always plan perfectly, and things don’t always go the way we planned. Here are some more scenarios:
1 - If you think the guy who lost his phone was not careful enough, let’s add that it was new user who just created his bw account to store his bank credentials in and hadn’t gotten around to figuring out a better place to store his master password yet. Then his phone got stolen.
2 - Here’s a different scenario. Let’s say you have multiple devices, all with ability to log into bitwarden, AND you have your master password safely written down on a piece of paper in your underwear drawer. Suddenly you’re woken up at 1:30am with a text message alert of some very suspicious activity on one of your accounts. In a panic you jump on line and change your your bitwarden password (typing it twice). Then you tend to some of your other urgent items. Then you try to log back into bitwarden but your password doesn’t seem to work. Somehow due to either the panic or the mental fog of being woken from a deep sleep, you didn’t remember your newly-created password correctly. All your devices are locked out. And you have no ability to change your password again. Is the thief locked out too? Maybe so, unless the way he got into your accounts (which triggered that suspicious activity to begin with) was keylogger so he was able to see what your new password was (in that case he might already have your entire database, but then again he might not, so the best we can do is secure the account as soon as possible).
3 - You’re on a camping trip 200 miles from home. You didn’t INTEND to do any business so you didn’t bring that hardcopy of your master password from your underwear drawer. But then just as you were cracking open a beer after a day of fishing you get that same alarming account alert email and you want to do something about it. You don’t remember your password and your underwear drawer is 200 miles away.
I’m sure there are plenty of other scenarios we could come up with to reinforce the same lesson. To me it seems like a basic security principle that the user should always have the option to immediately close or block his own account in some way (even if for some reason he doesn’t have access to his master password at that point in time). If we’re going to go down the what-if trail of someone breaking into our email to trigger an account deletion, then it seems we should explore the other what-if trails too.
You’re right there are a large number of possible scenarios to consider. Threat modeling is complex.
From a security point of view, if I have to choose between protecting against a scenario related to an attack and protecting against a scenario related to a user making several chained mistakes or omissions (i.e., if there is a conflict between these two options), I’ll generally pick the former.