Hello, today while changing my master password I noticed something: why do we have to enter the old master password in order to set a new one, and is this actually secure? Because if an account has been compromised, the master password has most likely already been leaked. That would mean an attacker could easily change it to a new master password without any difficulty.
An attacker does not only need to know the old master password, but also access to an unlocked device which requires successful 2FA at least once.
On the other way around, if you leave your unlocked desktop, someone could easily set a new master password if the old would not be required in the process.
1 Like
Isnât it more secure to use a different method instead of asking for the old password again just to verify our identity? (For example, a code sent to the email or a verification link.)
In addition perhaps, but not as a replacement. The master password is the most important item protecting your vault.
I was talking about the precautions taken when changing the master password. In my opinion, asking only for the old master password is not enough â an additional security layer should be used as well (for example, a verification code or link sent to the registered email).
It is only possible to change oneâs master password on the web vault. If you want additional protections against it being changed, keep your web vault logged out, set up MFA and make sure you donât click the âdonât ask again on this device for 30 daysâ checkbox.
You might, however, think about why this is important to you. To change the master password you need to be logged into your vault and know your master password. This is enough to completely view/vandalize/export the vault. In other words, it is already âgame overâ with your current vault. The only thing you can trust is using the offline backup you created last month as a to-do list for changing all your credentials.
1 Like
Actually, someone gaining access to the vault doesnât automatically mean âgame overâ anymore. Many services use two-factor authentication, and if you use an authenticator app, a password breach isnât necessarily irreversible. Thatâs why extra protections are important when changing the master password. If the process only asks for the current password, attackers can permanently take over accounts and you may not be able to recover them
If someone has âaccess to the vaultâ, that person already passed the 2FA barrier.
If the process only asks for the current password, attackers can permanently take over accounts
Even if you knew the master password of my vault, how exactly would you take control? You do not have the second factor to unlock the web interface.
What I meant was the two-factor authentication of the accounts saved in the vault
If an attacker somehow bypasses two-step verification, they can very easily change the master password and take the account. But if extra protection is added to changing the master password (for example sending a security code or link to the email), the attacker cannot permanently take over the account because your email has two-step verification and the attacker would need to get past that two-step verification. That takes time â during which you can log into your account, change the password, replace the two-step authentication token, and neutralize the attacker.
So the attacker âsomehowâ knows the master password and also âsomehowâ bypasses the 2FA?
In this scenario it does not matter if you send an additional e-mail for verification because the attacker already has access to the credentials of your e-mail provider.
If your vault is not generating the two-factor authentication codes (they are generated by a different service), then the attacker cannot have fully gained access to the credentials of your email provider, right?
If you mean that the authenticator service was hacked and all the stored twoâfactor authentication tokens were stolen, then yes, you are right â in that case sending a link or code to the email wonât help
Iâve thought about it â the second scenario is almost impossible nowadays. Many authenticator services use zero-knowledge architecture and end-to-end encryption protocols, so even if the authenticator service is hacked, the attackers would only get encrypted, meaningless data.
There is a relevant feature request here:
You are making too many random assumptions here. While master password and Bitwarden 2FA are available to the attacker, the 2FA for the e-mail service is not? That sounds like an artificial scenario and not very realistic.
The general recommendation is to combine a password always with a second factor. If an attacker gains hold on both of them, you lose.
I do not agree with this feature request. I think adding extra recovery options to recover the vault would spoil Bitwardenâs philosophy. There should be no âI forgot my master passwordâ scenario. If you think you might forget it, just write it down on paper. Bitwarden is cleverly designed: for unfortunate events like your phone breaking, they created the recovery code feature so you can deactivate two-factor authentication. The one thing you should prioritize and never forget is your master password. If you refuse to accept forgetting your master password, you must also accept that your data could be permanently lost
What I mean is there should be an additional security layer to change the master password, so that even if an attacker gains access to the vault they cannot completely transfer it to themselves
We should be prepared for every possible scenario 
From that point of view, it is impossible for an authenticator service that uses zeroâknowledge architecture and an endâtoâend encryption protocol to be hacked and for the tokens to be leaked, and that means a vault protected by twoâfactor authentication cannot be stolen
I think you missed the main point of the feature request, and focused on something not important. To be fair, the initial discussion in the thread is somewhat meandering; the meat of the ultimate proposal is clarified here:
The request feature requested cannot be used for âaccount recoveryâ, in the sense that it cannot be used for ârecoveryâ unless the user already has access to their unlocked account (through Login with Passkey, or Login with Device, or by simply having access to an app or browser extension that is already logged in). One of the use-cases for the requested feature would be to provide for passwordless authentication to provide access to protected actions (e.g., vault exports, changing master password), which currently require entry of the master password.
If the some form of the linked feature request is implemented, then it would be a short step from there to request an option to disable the ability to approve protected actions using the master password. I think that would address the concern that youâve raised in this thread.
Agreed. But @fetusyiyen one additional point I would like to throw in here â and indeed that is also one part of the general discussion of the shift from passwords to passwordless (especially FIDO) â is, that passwords are essentially phishable. And regardless of how strong your master password is, it will always still be phishable. Passkeys have the advantage of being âphishing-resistantâ (besides some other advantages).
I get that one can store TOTP elsewhere and pepper passwords, but disclosure is not the only threat. The attacker could also wreak havoc by deleting the vault entries, scrambling passwords, or manually writing everything down. Bottom line is that post-compromise you can no longer trust your vault to be complete, accurate and confidential. Changing your master password will not regain that trust. Nor will preventing others from changing it.
The only real way to regain trust is to delete the vault (after creating a fresh export). Then create a new one with a new master password, MFA, etc. and restore the backup you made a week before the compromise. Once done, start changing all your passwords one-by-one to regain trust in the sites themselves. To facilitate this (as you point out), it is best to keep recovery keys for each account somewhere secure so that you have a second-chance if the attacker beat you to changing your tictac password.
âEvery possibleâ is unrealistic. As an extreme example, I have not wasted time preparing for the sun becoming a red giant. Instead, I tend to focus on likely or probable scenarios. I have come up with a half dozen:
- I somehow âforgetâ my master password. For this, I have an emergency sheet.
- Somebody compromises my email and uses it to delete my vault. For this, I create occasional zip exports.
- Somebody gains access to my unencrypted vault. In that case, I follow the process I outlined above.
- Everything I own disappears in a house fire. For this I have offsite backups and an offsite emergency sheet.
- Bitwarden disappears off the face of the earth. In that case, I restore my backup into a competing product.
- I wake up naked and afraid in a foreign country. For this, I have memorized my spouse/kid/parent/bffâs phone number and can tell them where to find my emergency sheet.
You have just summarized Bitwardenâs architecture.
3 Likes
Oh yes, if such a feature is implemented it could provide extra security â sorry for the misunderstanding
I agree with you, passwordless is always more resilient and secure. I read the feature request and now everything makes more sense. Thank you, Bitwarden community moderation.
1 Like