Nested vaults to implement multiple security levels

Feature Requests Password Manager
1

This proposal is not for the faint of heart.

Most of us have passwords of varying levels of security. At the lowest level we have passwords for “throw-away” free accounts whose security we barely care about. At the highest level we might store, for example, cryptocurrency keys or passwords for other password managers. And there are passwords at various levels of security in-between.

The feature request here is to support nested vaults. Your password as before unlocks your main vault. But within this vault you can have other vaults, each with its own password. And once you implement a vault-within-a-vault, it should be easy to extend that to N levels of nested vaults, N being limited only by available computing resources.

At each nested level, yet another password is required to unlock that level.

Passwords that need a high level of security might be stored in a vault that is three or four levels down. To access that vault, you would need to unlock each containing vault first.

The general idea that I am proposing is ancient. it used to be called a “ring system” in operating systems, in which you had nested rings, and the deeper you went the more privileges you had. The idea of security levels is also implemented in classifications such as Confidential, Secret, and Top Secret.

In normal operation, the user would enter his normal Bitwarden key. This would unlock everything in the main vault. These would be all the low-security passwords only. The user can unlock a high-security nested vault as needed, making more higher-security passwords available, but still keeping the highest-security passwords inaccessible. Only rarely would the user need to unlock more deeply nested vaults. And the user might choose to unlock higher-security vaults only on a very secure machine.

So you could safely use your password manager while in a coffee house, keeping only the main vault unlocked and only the less secret entries possibly-exposed if somebody snatched your laptop from you.

Likewise, while crossing international borders, you could unlock the main vault under duress, while being unable to unlock nested vaults because you would not have the higher-security vault passwords with you when traveling.

Each nested vault would preferably have its own timeout, and most users would set the timeout shorter for higher-security vaults.

Searches would presumably only work on unlocked vaults.

2

Nested vaults might make these features unnecessary:

Auto-logout after X minutes

Require master password “re-prompt” for some items

2FA when ‘unlocking’

3

I mean, you could technically do nested vaults right now just make two bitwarden accounts and store a fully random string in your “outer” account, and have the master password for the “inner” account be the string given when concatenating the random string from your outer account with your “remembered inner account master password.”

Then just open two browser sessions (Chrome has a user profile feature) and log in to one, then grab the random string and log in to the other at the same time.

Though perhaps streamlining a process similar to this could increase usability.

4

I think you can achieve the same effect using “PROFILES” where each profile is limited to some specific subset of entries in your vault. The same entry can exist in multiple profiles - it databases, this is similar to applying a view filter to a table.

The way it would work is that each entry is encrypted with its own key. That key for that entry is then encrypted with the master password key. When the entry is “added” to a profile, the master password key unwraps the entry’s key and then encrypts it with the key for the profile the entry can be now accessed in.

The trick is to make sure that the settings (entries) regarding control and security of the Bitwarden account itself cannot be applied to a profile. If information must be visible (i.e. read-only), then a separate copy of that entry can be made and the profile key can decrypt it like any other entry, however the bitwarden app itself doesn’t honor or look at the read-only copy. Meaning changing it in the profile’s view of the vault will never be processed or read by the app itself - it would only access the master profile’s copy as that is the only read-write copy. Of course, access to the master profile would require re-authenticating to obtain the elevated privilege.

5

This seems like an essential feature for heavy users. I have Bitwarden installed on a plethora of devices, offering all manner of easy unlock methods. I dare not use them now, however, since that means unlocking everything about my vault with such an insecure method.

Whether implemented as nested vaults or profiles like mike808. The essential part is being able to assign secrets class or whatever such that they can only be read, not written, with insecure authentication or not read at all without entering the master password or maybe even require reentering the master password every time they’re needed.

The entries can either always be visible, but the secrets not, or even the visibility of the entries could depend on the security level.

Is there anything like this under consideration?

7

I definitely like this idea, not just for the increased and more flexible security and the fact it would completely hide certain entries, but also because it would make it a lot easier to use. Many of my entries could be in the outermost vault, with only a password, making it very easy to access that stuff on any computer or device, so something like posting here in the forum could be done on a public computer without jumping through hoops to login. More important entries, like email, banking, etc, could be further locked down, where I’d need another password and/or keyfile to unlock them, making them harder to access but more secure.