2FA recovery code generation

Does the recovery code get generated even if I don’t click on “View Recovery Code”?

I’m asking because I specifically don’t want a recovery code. I use a strong password and Yubi keys. If either are lost, the account also being lost is in my recovery plan.

If a code is created without my visibility to it, how does Bitwarden protect it? It is encrypted with my key?

Yes, it gets generated the first time that you activate Two-Step Login for your account. All sensitive information in your vault is locally encrypted with your user encryption key, using AES-256 encryption.* On Bitwarden’s servers, there are two additional layers of encryption at rest.

 


*Edit: The recovery key would not be encrypted with the user encryption key, as noted by @Neuron5569. The other encryption layers should still be applicable.

Hello,

I think these might be “undocumented” questions. Here are some possible answers based on code search and reasoning:

  1. When you set up 2FA, the recovery code is generated immediately. Search for the string repo:bitwarden/server "TwoFactorRecoveryCode ="
  1. Some 2FA authentications are based on a shared secret, so Bitwarden would have to have access to these secrets without user-side encryption. The 2FAs that don’t rely on shared secrets include WebAuthn (security key), third-party providers like Duo, etc(?). Recovery codes are a shared secret.

However, by infrastructure, Bitwarden’s database information is stored encrypted with keys managed by Microsoft. So, it’s not in plaintext, but it’s encrypted in a way that Bitwarden can access it.

1 Like

In addition, addressing your possible unsaid questions, if Bitwarden servers were compromised (e.g. as in Lastpass), and all the encryption keys were lost, or not explicitly clarified, I’d assume the following information might need to be reset:

  1. TOTP secrets
  2. 2FA recovery code
  3. API key

However, your password is generally not breachable from the Bitwarden side. Your account will be safe, but you may have to reset the above info. Personally, I plan to also:

  • Change the email
  • Change the password
  • Rotate the encryption key

Because even if they have the encrypted vault and encrypted encryption key, if nobody has a master password or the encryption key, including myself, “nobody” can decrypt it.

1 Like

Thank you for the information and replies.

I’ve read the Bitwarden whitepaper along with the info you guys provided and think I’ve arrived at what I believe are my most likely threat vectors, both of which have mitigating factors that make them unlikely. Bear with me, I’m a bit paranoid of keeping secrets in a vault on the internet. My rational side says it’s as safe as my current KeePass setup, but like most people I’ve already been the victim of data breaches so I wan’t to make sure I’ve got this right.

My greatest threat would be malware or some type of cyber compromise of my workstation where the attacker gets my password from a key logger. In that case, I would be proteced as they would’t have the ability to authenticate without the Yubi key. Although there is a recovery key, they can’t get it from me as I don’t know it, didn’t record it. If I understand correctly, Bitwarden can’t reveal it without fully authenticating first, and to do so it’s either password + Yubi or password + recover code. They have niether the Yubi or the code. No other combination will get them in. They can’t get both. I’m I looking at this correctly?

The second threat would be malware or a compromise of the server. Vaults have all master key encryption done client side so I suspect using my vault locally would still be safe in the event of an unlikely issue on the server tier. If an attacker somehow got recovery codes from Bitwarden (highly unlikely), they are useless without the master password. Again, they can’t get in.

This is my position:

  • Email address not used anywhere else and has a set of characters appended with a plus.
  • A password with 5 random words and 6 random numbers, plus another trick.
  • The password is only recorded in a protected offline location and in my memory.
  • Argon2id.
  • Yubi keys in FIDO2 mode as the only 2FA (5 of them all tested).
  • The 2FA recovery key is not known to me so it can’t be compromised from me.
  • I will primarily use Bitwarden on a single laptop that only connects to low risk sites, no general browsing at all. It is well firewalled and up to date.
  • I absolutely don’t click on phishing emails, nor am I curious enough to open them. I don’t even trust unexpected emails from institutions I deal with unless I initiated the email and expected it. Very careful in this area.
  • I’m far from a high value target. But apparently with AI generated customized attacks getting better and more common, we all will likely be targeted more in the future.

Is my assessment okay?

If you are not doing it already, I would add “always authenticate with 2FA, not using ‘Remember me’” option, as those persistent tokens can also be stolen by a malware.

1 Like

I agree, this would be the most likely attack vector for a cautious user who uses a password manager. Not the only one, but the one most likely to succeed.

If the device where I use my password manager is compromised, I wouldn’t count on 2SV protecting my account.

The attacker can easily get the master password with something like a keylogger. And the encrypted vault with an infostealer. Which they could decrypt because they had the master password (without needing my second-step login method).

With 5 security keys it’s not very likely that you would need the 2SV recovery key. But I would record it in my emergency recovery sheet. All the yubikeys could be disabled at once by accident, there is a button in the web vault that does exactly that, there’s also software bugs that could happen.

I consider myself a cautious user, but I would never affirm something like this.

I would say “I always try not to be a phishing victim”.

I don’t think anyone is immune to a well crafted enough phishing attempt if one’s caught in a moment of distraction (and I’m not even talking about a spear-phishing).

It looks pretty solid.

1 Like

Suggestion as you didn’t mention it yourself: encrypting the system/disks, especially for a device that could get stolen or lost.

Another one is, if you “Login with Device”, you practically never have to enter the master password on the keyboard and hence is less likely to be keylogged.

If there is malware on your device, it doesn’t need a keylogger to steal your data. As soon as you unlock your vault, all of your secrets are decrypted and stored in plaintext in the memory of your device. From there, malware running on your device can exfiltrate the vault contents simply by creating a memory dump (or by more selectively searching the memory for information of value). The malware will not need your master password (or 2FA) for this.

Thus, your main tactics for protecting your data are/should be:

  1. Strong malware defenses: This means impeccable internet hygiene (i.e., not downloading random files, clicking random links, opening random email attachments), strong security settings in your browser and firewall, always using up-to-date anti-malware software, keeping the operating system and apps up-to-date, etc.

  2. Keep the Bitwarden vaults locked at all times while not actively being used to autofill or look up information. This increases your chances of being able to detect/mitigate malware before it gets access to your vault data.

  3. For critical passwords stored in Bitwarden, use 2FA credentials that are stored on a device where you never use Bitwarden (e.g., a Yubikey). This allows you to protect your most important accounts in case your Bitwarden vault is compromised.

Good points. One thing I’m doing while moving into Bitwarden, is leaving behind unnecessary records in an archive kdbx file. This leaves me with a smaller subset of entities to respond in the case of a compromise. I’ve also been evaluating each entry and using methods to not fully reveal all that is needed to authenticate, such as an alias for the email address field if it’s used as the username. The actual address is not relatable, nor elsewhere in the vault. Not foolproof, but something to slow down an attacker.

Yes, you are correct here. Mistakes do get made.

I’ve been encrypting every disk for years as the default. Losing an expense device to theft or loss wouldn’t be a fun experience, but losing it and all financial, legal, academic, and business records to the new owner at the same time would be disastrous. This goes for what’s online as well.

Thank you, I’ll take a look at that.

@grb Informative information. I didn’t realize the contents were in memory. This further reenforces my recent move into a new password vault. I was storing almost 400 entries in my kdbx file. Far, far too much for an actively used vault. The bulk of that will not be transferred to Bitwarden. Less entities to manage and respond to if needed.

I’ve also considered using a separate app for TOTP codes, and now will do so for sure. I use 2FA methods in a descending preference based on security, Yubi > TOTP > with phone or SMS as a last resort. Keeping all those out of the vault should slow down or defeat an intruder.

Based on reports on reddit and this community, by far the greatest threat is losing access to one’s own vault. Although you have your master password written down, Yubikey still appears to be a single point of failure. We have no way of knowing if Yubikey may suddenly fail us some day (e.g. on Jan 19, 2038).

There are two primary mitigations:

  1. Add your recovery code to your emergency kit [1,2,3]. Do keep in mind that the recovery code only allows one to download the encrypted vault without MFA. It does not facilitate decrypting the vault without the master password. It is a much smaller threat vector than what one traditionally thinks of with a recovery code. The impact being similar to a server compromise.

  2. Maintain backups with a frequency equal to your loss tolerance. And, keep in mind that KeypassXC can read Bitwarden’s password-protected JSON export format.

As a disaster prep exercise, one ought to practice regaining vault access solely using the emergency kit and also solely using the backup.

You might check out Pepper for your password. It is the formalized process for this. By extension, one could similarly do “Pepper for your username”, leveraging email plus-addresses. If you do go down this route, be sure to add your pepper to your emergency sheet because TBI and death both happen.

One other thing to consider is that at some point you will die, and your spouse/executor likely will need access to your credentials to include your assets in your estate and to cleanly shut down your online life. As you add complexity, make sure you thoroughly document it in a way that your executor will understand without being able to ask you any questions.

Along similar lines, Biometric unlock has the same benefit, typically storing the vault decryption key in your device’s TPM. In addition to minimizing keylogging, reducing authentication friction makes it much more tolerable to keep your vault locked when not in active use.