Strengthen encryption with hardware/platform key

Are there any plans to strengthen the encryption model using a second factor?

Given the LastPass data breach, I don’t think protecting only the client communication with 2FA is good enough, although Argon2 is a step in the right direction.

I understand this question has been posted many times on this forum, but it looks like CTAP2 might be able to support this, now.

https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-hmac-secret-extension

It looks like there is a bit of conversation about this in the following thread:


It looks like passwordless login r&d is on the roadmap for Q1 2023, but this sounds like only for downloading the vault, like the current 2FA. It also mentions passkey support for “future” development, which might be referring to decryption, but I’m unsure.

It would be great to get some employee commentary.

Best,

Craig

2 Likes

Hey all, Bitwarden recently added multi-encryption to the database, see Data protection for user columns at rest by kspearrin · Pull Request #2571 · bitwarden/server · GitHub for details.

I’ll start off by saying I only know the very basics when it comes to encryption, so explain like I’m 5.

It’s my understanding that 2fa is currently only used for downloading the vault, and only the master password is used for actually encrypting it.

While this is certainly beneficial for general security, it does nothing should bitwarden’s cloud server ever be compromised.

I would like the ability to (optionally, of course) use hardware 2fa (yubikey, open key, etc) to encrypt the vault itself in addition to the master password.

Essentially, I want to use a hardware 2fa device in the same manor as 1password’s “secret key”

This essentially gives me 2 “passwords”. One I know, which is limited by my human memory, and one I keep, which isn’t limited and can be vastly more complex. I can’t help but think this would be vastly more secure, should my vault ever get stolen somehow.

As far as how I imagine it would work is that you would enter your password and then be asked to either tap NFC key (if you were on a phone, for example) or insert/tap the USB dongle to log in. Pretty seemless UI experience at least.

Is this something that could be added to bitwarden?

While I wouldn’t be interested in doing so, I imagine it would also be fairly simple to implement at the same time the option of ONLY using the hardware device.

1 Like

Hey @Yoyoyoboyoyoy the team just released a blog on multifactor encryption and how it protects the database.

Thanks @bw-admin

(Once again, disclaimer that I’m not a security expert by any means)

Reading through that, though, it doesn’t seem to match up with what I’m requesting.

The blog talks about having multiple levels of encryption on the server, not the client. (Obviously a good thing, don’t get me wrong, just not what my request was)

Adding more walls to the castle is great, but the war against would-be hackers is always an arms race. Obviously, password manager providers are going to be prime targets for the best of the best cyber-thieves.

If someone were to get in and export vaults, the only thing that stands between the hacker and user’s data is the password. And while good passwords are always important, I’m ultimately human and memorizing a truly random 75 character password is something that’s not really feasible. (Nor is inputting a password like that practical).

I could use a yubikey to simply type in an outrageously long password as a macro for me, but then I’m shifting my security from something I know to something I have, which has tradeoffs.

By using a hardware device as a secret key, I can instead use a more reasonable password while maintaining a much higher resiliency against brute force attacks.

First and foremost, you should keep your devices secure. Lock them when not in use, and do not let other people use your devices. For added security, you can use various available solutions for whole-drive encryption (e.g., Bitlocker, VeraCrypt, etc.).

Second, there is absolutely no need to use a random 75-character password.

Your master password should be a a randomly generated passphrase, consisting of a string of words that have been randomly selected from a list of 5000 or more words (using a passphrase generator). Even using a passphrase of only 4 random words should provide sufficient security for the vast majority of users. For added security, some users prefer to use passphrases consisting of 5-7 words. These passphrases can be readily memorized with a little bit of practice, they are easy to type, and they provide all the security that you need for your vault encryption.

Random passphrases with words selected from a 7776-word diceware wordlist (such as the EFF wordlist that is used by Bitwarden’s passphrase generator) provide 13 bits of entropy per word, so you would get 52 bits of entropy with only 4 words, and 90 bits of entropy with 7 words. There should be no need for higher master password entropy unless you are a highly targeted “Enemy of the State”.

Obviously 75 is an absurdly high number for the sake of example.

Using a secret key isn’t necessarily for increased local security. Usb sticks can be stolen. Etc.

My primary concern is accounting for security that is outside of my control (my data on a random cloud server).

Googling bits of entropy, adding a secret key would bake in 128/256/512/whatever bits of entropy against anonymous attacks, if I understand correctly.

Obviously attacks targeting a specific individual rather than a collection of data are a very different thing, but that’s not my reason for this request

@bw-admin already responded above (here and here) to explain that the data stored on Bitwarden’s servers are already encrypted using mulitple layers of encryption (not just your master password, although that by itself should already provide sufficient security if you follow my recommendations above).

Your response implied that you were concerned about the encryption on the local device, not on the cloud server (“The blog talks about having multiple levels of encryption on the server, not the client. … If someone were to get in and export vaults, the only thing that stands between the hacker and user’s data is the password.” — this is applicable to your local device, not Bitwarden’s server).

For security of your devices, please refer to the advice I gave above. For security of the cloud vault, please refer to the information that was provided by @bw-admin.

My concern is that while a “enemy of the state” level talent is highly unlikely to care about a John Doe like me, they could potentially attack the bitwarden servers. Extra encryption on the servers is always good, but ultimately those keys are stored with the castle.

The concern I have is that my vault (along with many others) would be lifted (in its encrypted state) from the server by such a talent, then sold (or dumped) online where lower-level talent(s) would attack the vault itself.

As a computer-literate but otherwise average Joe, this is far more likely to affect me than someone specifically targeting me and my vault.

Yes using a very long password/passphrase would achieve the same un-brute-forceable result, but security is always a compromise. There’s a significant loss in practicality having to always type out an incredibly long passphrase compared to a 15ish character password and tapping a yubikey.

Anyway, I think I’ve made my case. If smarter people than me think that the extra encryption on the server is enough to make it infallible to break-ins, I guess I’ll defer to their judgement as I’m not remotely qualified to say otherwise.

In addition to Azure’s encryption (TDE) of Bitwarden’s database servers, the contents of your vault are protected by AES-256, what is known as “military grade encryption”. The “256” in AES-256 means that Bitwarden uses a 256-bit random number as the encryption key to lock each cipher string that is stored in the encrypted vault database. This is equivalent to a random 77-digit decimal number or a random string of 55 lowercase letters. On average, attacker would have to make 6×1076 guesses before stumbling upon the correct key. Cryptography experts consider AES-256 encryption to be uncrackable, even using quantum computers.

This is great :100: and I really appreciate how this can provide extra protection to all users, without them needing to do anything. That being said, this seems like it really only addresses the smash-and-grab of at-rest data threat (albeit very important) and doesn’t address the root issue, which I feel is that humans can’t be trusted to use strong passwords. To clarify my point, I couldn’t imagine that it would be too difficult for someone like a Bitwarden engineer to uncover the data at-runtime (protected by master pass only) that is not protected by TDE, but I’ll admit that I’m not familiar with Azure TDE. This somewhat goes against the original Bitwarden encryption model, where the user holds the encryption power to the vault.

Just to refocus this Feature Request, I would like to be able to use hardware/platform keys to strengthen the user side key derivation. I feel that protecting such high value data with effectively a user provided password just isn’t good enough. I would feel much more comfortable knowing that weak employee passwords won’t compromise the entire Organization’s shared vault.

Couldn’t you accomplish this with Yubikey static password? You could (1) use it alone with entropy as high as you wish; (2) add a little salt to it; (3) append any length master password you memorized to it. Something you know + something you have, resulting in extremely high entropy. It’s not the solution I use but it does overcome the ‘human memory’ weak link in the chain.

Yubikey static password+appended user password would accomplish what I desire. Significantly increased entropy protecting the vault prior to it being uploaded to the cloud.

However HID emulation can be a bit finicky, especially on mobile, and it might “press” enter after entering the password, not allowing you to append what-you-know to the password.

And the other issue is that this is incompatible with NFC, which is a big bummer.

Good point on NFC access. I am going to test static passwords via NFC and see if there is a possibility.

I doubt many think that. Your goal of strengthening the zero trust component of the BitWarden architecture is commendable.

The encryption on the server is really lovely but it is not zero trust.
I think the main protection we get from BitWarden is the zero trust architecture. That is the client side encryption based on the stretched master key. This is the part that is “zero trust”.

This summer (2023), 1Password are planning to implement accounts based only on passkeys which I don’t think even have a master password at all (or secret key).
I think BW will be watching what happens with 1Password and I expect BW to respond then (if they haven’t already started)

Summer will be hear soon.

Bitwarden has already acquired passwordless.dev, have passkey integration on its roadmap for 2023, and are members of the FIDO Alliance group that is developing the standard.

Yes, 1Password’s new implementation will not require a master password, its secret key, or 2FA. HOWEVER, read their announcement closely. The first phase of passkeys which allows you to sign on to 1Password via a passkey is being executed by Apple and Google’s passkey solution, not their own (read: you can already try this out on eBay, BestBuydotcom and some other sites). Their own is to follow. It’s a quick win to claim they were first to market. Full passkey integration via their own service will be later and they drop a few caveats in their demo video as there are still some unknowns. I suspect 1Password, Bitwarden and other leading password managers will all get there around the same time.

I haven’t seen any details of the plans though.

The plans? You mean pricing? If so, I would imagine that would come last. But, I did see somewhere that passkey support would be included in its base plan. I can’t remember where I saw this. But, if you think about it, it makes sense. Apple, Google, and M$ are already offering it for “free” and Bitwarden needs to compete with other password managers on market share. My guess is that some of the niche aspects of passkey functionality could be locked away in a premium tier but the core functionality will be made available to all plans. Bitwarden already has an incredibly feature rich free plan compared to its competitors and a fairly priced premium plan. Just a guess.

Also, password managers will have an ever decreasing market as passkey support becomes widespread. Once a tipping point is reached for Apple/Google, it will become ubiquitous quickly, I think. Look how successful Google’s and Apple’s third party sign in already is (with ‘hide my email’ and biometric sign in for Apple). With passkeys , No password to remember or store, No 2FA, way lower risk of server-side hacks, and dead easy user experience are pretty compelling. I don’t know how password managers compete effectively in that world. For me, it will come down to being able to own my own keys. But, most consumers won’t care about that or even think about it being something that has value.

No I mean plans as in what will they actually deliver, not pricing plans. :slight_smile:
My current focus is on the account encryption key (also topic of this thread).

How will that key be derived without a master password? I speculate that it will be a random key encrypted with the FIDO2 public key and stored on the (e.g.) Yubikey but that’s my speculation.
I think the first actual details we will see will be from 1Password and that will reveal what is actually possible.

I have seen the 1Password video (you referenced earlier) and noted it used Apple’s iCloud keychain but I thought that was just an example and could just as easily have been a yubikey, or maybe they will rely
on some extension to FIDO2 that yubikey etc don’t support yet? I haven’t seen anything conclusive either way.