Add 3x protection to Bitwarden database

Feature Requests Password Manager
, , ,
1

Currently users data on Bitwarden servers and cached copies on disk are only in essense protected by users passphrase. Lets improve this.

I recall some password manager (1password? What?) has this security system, where the data at the servers and local cached copies are encrypted using a key, but that key is encrypted with a key created using both users passphrase & securitytoken1 (256bit random data essentially). This security token is never stored in the servers, not even in encrypted form and only exists in local password manager(s). When user signs into password manager, existing password manager must accept this sign-in and give a copy of this security token to that password manager, so it can decrypt the database (with users passphrase ofcourse). This is done in secure manner providing a challenge-response mechanism to ensure user is really giving the token to the proper password manager in encrypted form to prevent hackers and even Bitwarden from sniffing it from the traffic. In local cached copies / password managers that have been locked, the security token is encrypted using users passphrase, so its only needed once per database cache/device is activated.

This basically gives 2FA + prevents password manager company from sniffing out your passphrase, if you sign in via their website, so that they could decrypt your database (incase of request from police etc.). Anyone getting your password cant decrypt any databases from the servers if they hack them, since they need the token too.

A great feature we should add to Bitwarden, but let me make it a bit better:

How about ALSO having a securitytoken2 that would be stored only in Bitwarden servers and only given to the app during the opening of the app (if user can identify to the servers, meaning that everything is ok) when its locked? This token, nor its encrypted copies would NEVER be stored in app or caches, only in programs memory for a brief moment when needed (and Bitwarden servers).

This basically means that cached copies of the database stored in computer, phones, etc would be unusable to any hacker who gets access to them, even if they knew the passphrase, unless they can also properly authenticate to the Bitwarden servers. User, who has their computer of phone stolen, could easily simply sign into Bitwarden and revoke access to those computers/phones, giving 100% assurance, that even if the attacker has he’s passphrase, they can not decrypt the cached copy stored in the device.

So…

How about combining these 2 (or 3 to be more exact) different things together to create ultimate security solution?

1) The key that is only stored in servers and never in the devices (only in device memory for a brief time it is needed)
2) The key that is only stored in devices and never in the servers.
3) Users passphrase

All 3 would be needed to decrypt database that is stored in the Bitwarden servers, but could only be decrypt in devices (since Bitwarden servers never have access to key 2).

Key1 would give 100% protection against local attacks against local cached copies, even if attacker would have key2 and key3, since attacker cant login to Bitwarden servers to get key1. Key2 would give 100% protection against Bitwarden servers compromise and even authorities forcing Bitwarden to comply to get users data unencrypted + it would act as a 2FA for new logins. Key3 would be users passphrase, unknown and unsaved to anyone.

Ofcourse this would prevent offline use of Bitwarden, since without key1 = online status you could not open the database. So this could be optional feature advanced users might want to enable.

1 Like
2

But how about backups of the database and how to prevent users from being locked out of their database if they accidently logoff all their Bitwarden sessions on all of their computers, you might add?

Well, backups of the databases stored locally could be encrypted as they are now, or unencrypted as they are now, so this would not affect them in any way. User being able to access the database in the computer/phone completely could and should be able to do whatever they want with it, including store a local copy for safekeeping if they wish.

Recovery for the account / data could be done with a simple magic of PKI. When creating an account, user would be given a recovery seed of their account, that would essentially be ECC private key. All account data would be encrypted with keyX (protected by many means as described earlier) which copy would also be encrypted with ECC public key of the user and stored in Bitwarden servers. When new data is stored / database changes, the old key could be overwritten with latest key encrypted with ECC public key. If user needs to recover their account, they could simply proceed to account recovery with their ECC private key and voila, would have access to their database again and would have to setup new password and new security tokens etc. Ofcourse, this key should be 500+ bits ECC or hopefully using even quantum resistant PKI against future threats.

(Ofcourse this recovery key should be only shown to the user when they create the account and created in users end, not in the servers…if this key is available to users with simply their passphrase and sign-in, then it would defeat the purpose of the key2 discussed earlier…attacker could simply grap the recovery key and recover the account without the key2, this must not be allowed to happen!)

3

You might first read Bitwarden’s Security Whitepaper. Many of your ideas are already addressed in some fashion.

“Key file” and “Secret Key” are the terms I have seen for this concept. Bitwarden has stated that they have no plans to implement this functionality as they have similar protections that do not increase user-overhead.

If a keyfile is important to you, you could (somewhat inconveniently) simulate one by appending to your typed master password a random string copy/pasted from a file you keep on your device(s).

Turns out that your vault is only ever decrypted on your device, even when using the website. And, your master password never leaves your device. It is never transmitted over the Internet, and it never is given to the Bitwarden servers.

If logged out, the entire vault is removed from your device. A cached encrypted copy is kept if you keep your vault logged in, but locked. When locked, the decryption key is not (directly) on your device. It is either regenerated when you type your master password, or it is retrieved from your hardware security device (the TPM) if you enable unlock with biometrics.

Many people have reported they value the current read-only access to your vault when the cloud storage is under maintenance or you have no connectivity.

In a sense, this “optional feature” exists today in that one can completely protect their vault by setting the timout action to “logout” for maximal security and to “lock” to support offline use.

4

@mmja I modified your feature request title to remove a superfluous and potentially misleading claim (old title: “Add 3x protection to Bitwarden database instead of current 1x protection”; new title: “Add 3x protection to Bitwarden database”).

To contribute to the Bitwarden code base, start here.

In addition, before doing anything else, I would strongly recommend that you familiarize yourself with Bitwarden’s security architecture, by studying the following materials:

 

Finally, you should know that Bitwarden has no plans to implement anything equivalent to 1Password’s “Secret Key” (which is what you seem to be referring to with your “securitytoken1” suggestion), as explained here.

Also, Bitwarden clients are expected to support off-line use, but you already know that.

5

Well, it does not have similiar protection.

Yes, when everything works fine and you dont have to comply with goverment officials or nobody places a trojan into your www-pages etc. When you do, this is what would happen:

My system would prevent that from happening, since there is no way for Bitwarden to get key2, especially if user refuses to download “updated” versions of the software (that could be backdoored by Bitwarden or hacker).

Currently I do have to sign into Bitwarden www-pages, where you could pick up my password if ordered by police etc. to manage my subscription etc. This would not change in my scenario, but in my scenario, even if you got my password, you still cant decrypt my data, since you still dont have the key2. This IS the point of this.

It matters not. If attacker steals my computer and later finds out what my password for Bitwarden is, he can decrypt that vault. THE WHOLE POINT of this key1 is that it would NOT be possible after I simply deauthorise that session, because user could not download the key1 after that sessions is deauthorized. Why did you forget this completely? This IS the point of this.

That is why it should be optional.

If I logout every time, then I also need to do 2FA to log back in every time, which is big hassle. (Yes I could click not ask for 2FA for this Bitwarden for 30 days, but that would also lower the security incase I do sign out and want to remain secure - wanting 2FA for this Bitwarden after this. If attacker graps my computer when this settins is set and he can gain my password, there is nothing I can do to prevent my entire Bitwarden vault to be opened by him, because he can simply login with this vault with my passphrase - no 2FA is needed for 30 days - and get the data. In my scenario, he could not, because I would deauthorize that sessions to my computer the minute I realize my computer has been stolen.)

In my system, there is no need to do 2FA after opening locked Bitwarden vault, since retriving the key1 happens on the backround after I type in my password/Windows Hello…you would not need to log out, you could just lock it and be as safe.

6

Please take some time to actually read the information that was linked above. Also, please be advised that continuing to make unsubstantiated claims here may run afoul of the forum rules that require participants to “avoid spreading misinformation”.

The Hushmail scenario would only apply to the Web Vault.

No system (including yours) is immune to a supply chain attack, and all systems (including Bitwarden’s current system) are immune if the user refuses to update their software.

1 Like
7

… are immune - or are not immune? :thinking:

8

I’m talking specifically about a supply chain attack, which is what the OP was concerned about. If you start with a clean version of the software, and do not update it, you will be immune to supply chain attacks (although you may expose yourself to other security vulnerabilities, unrelated to supply chain attacks).

2 Likes
9

Sounds like you might be satisfied with two separate passwords, one for login-to-vault and the other to decrypt-vault. Since Bitwarden has already stated that they will not be developing a keyfile, perhaps that could be the subject of a FR.

If one deauthorizes sessions, it also removes the 30-day MFA suppression.

1 Like
10

This could kinda do it, but Im thinking more a system where one could manage ones subscription etc. from Bitwarden pages with “admin password” and just use the database/vault with “user password”. Compromise of one would not lead to compromise of the other and would also provide benefits like:

  1. If “user password” is compromised, user could log into Bitwarden pages with “admin password”, reset the “user” password, signout all sessions and recover the account using recovery seed words.

  1. Attacker could not completely hijack the account if they only know the “user” password, since only thing you can actually do with it is to open the vault (after 2FA etc.)…they cant change “user” password without also typing “admin” password, nor they can change 2FA:s, etc. etc.

  2. If “admin password” is compromised, attacker can control the account, but they cant decrypt the database data (nor they can do account recovery without recovery seed words).

  3. One could easily maintain or help others to maintain their Bitwarden accounts, like buy and make ones for them (like your kids, your wife, your parents, etc.), since you, as an “admin” could not decrypt their data, but you could setup their 2FA, pay for their account and if needed, help them recover their account. With 1 password doing all, this is not possible in secure manner.

“Not putting all the eggs in one basket”…“user password” is the password people would be typing in 99% of times and that is the one that is therefore more easily lost or hacked. Now, if that happens, its game over. Then, it would not be.

Edit:
I hope they change their mind, since it would be a major security upgrade as I pointed out earlier…but Im not talking about physical keyfile…Im talking about additional key.

Ok, this is a good thing.