Encrypt vault with Master Password/PIN + security key
Feature function
From my understanding, Bitwarden vaults support the use of security keys used for unlocking a vault. In the event of a vault breach like what happened with LastPass, I would like to know if we can use something like a YubiKey as a additional key to be used in the vault encryption process. If the Master Password is guessed, it is my understanding that the YubiKey secrets are still needed for a vault to be decrypted offline if the vault is ever stolen.
i think I understand this better now after thinking about it some more and reading your comment. I can just achieve the same protection by just using a more stronger password, because the secret from the yubikey would just be another long password that could be cracked as well. Seeing it that way, it doesnât add much more protection, itâs the same kind of protection as the master password.
But if the encryption key is derived from the yubikey (or other secure key device) you wouldnât need a strong master password. A short and easy to type password would be secure.
In fact I think the end goal should be to have yubikey only with no master password at all.
I use Yubikeys across services. They can serve different purposes. WebAuthn and Yubikey OTP are for 2FA. They authorize a device to receive the vault. They play no part in encrypting the vault. The LastPass breach effectively bypasses this local 2FA by stealing your vault from the host. At that stage, you only have your Master Password protecting you.
HOWEVER, you can also use the Yubikey as part of your Master Password workflow. It works the same way as commercial banking fobs where you enter a PIN (something you know) and then type the rotating pin code (something you have) directly after it. In the Bitwarden/Yubikey case, you would set a Yubikey Static Password. When you get to the Master Password field, you tap (again, something you have) the key for the static password to insert. You then type your password (something you know) right after it.
Now, if you already have a long, complex single-use password or passphrase, it will already take centuries, if not more, to crack. Adding the static password serves no practical value unless you need to protect your data for a few more millennium. But, it does serve a value in making it harder to steal as someone would need to find and steal both and put them together to get access to your vault.
Your other two options are to use only a Yubikey Static password (passwordless sign on) but you better protect that key from local theft and/or put a pin on it. Or, you could use a really poor password plus the Static Password, so it would be easy to remember but still very complex, in sum. I personally would never do this. So, you have a few options and use cases.
@222 In your second paragraph, that is the situation I would like to see implemented. Iâm new to the use of security keys and appreciate everyoneâs insight on it and itâs use cases. I believe it would be great for my family members to use a somewhat strong password and let the Yubikey static password pad the rest of their vault. For the security it adds in that regard, I believe it would be nice option for bitwarden to offer.
Yubikey static password is more vulnerable than a memorized password, as it can be stolen physically in addition to MITM/phishing/keylogging.
It could be useful as an accessibility feature though for folk for whom there are no secure 15+ character passwords that they could memorize who may currently rely on post-it notes.
Agree. Bigger risk is loss. Static password + memorized password is a strong combination in thwarting theft, though its advantage to mitigate brute force is academic if you have a strong memorized password.
Although there are some similarities, the two threads are asking for distinct features: The other thread is requesting protection of the account encryption key to be done with the use of an additional secret to be stored on the same device that stores the protected key and the cached vault. In contrast, the Feature Request in this thread would protect the account encryption key using an additional secret stored on an independent device (i.e., the security key) â away from the the protected key and the cached vault. The security implications are very different, so I think it makes sense to keep these two Feature Requests separate.
If we leave this thread open, it wonât get traction, but if we include this proposal in the other thread, we might have a higher chance of adooption.
If youâre talking about a secret key as implemented by 1Password, then the above statement is off-topic (because this topic is about security keys, not secret keys).
[The quoted post and follow-up replies were moved to a separate thread]