Automatic prompting and then appending upon autofill would require Bitwarden store the pepper in memory on your computer. This would not reduce your vulnerability to memory-dumping malware installed on your PC, which also happens to be the only location that your decrypted vault ever resides.
As for the security of your encrypted vault, it can be improved either by using a longer and randomly generated master password (passphrases make this easy), or by messing with your encryption settings.
That part sounds like you’re requesting another “password” besides the master password (similar to what 1Password does with their “secret key”?!).
What exactly does “When BitWarden enters a password it enters 123456abcde.” mean? – I mean, Bitwarden does not have the master password and doesn’t enter it… so I’m not sure what your idea is here.
@grb Thanks. I think I understood the peppering part, but I wasn’t sure (and didn’t really understand) if @NoNameEntered wasn’t suggesting more than that at the same time with the request.
But, if “peppering” is the whole request, I think then it’s basically the same as this feature request: Mot de passe combiné [Combined Password] and could be merged.
I think the only difference is that @NoNameEntered proposes that the client should prompt for the pepper during login, and then store the plaintext pepper in memory while the vault is unlocked, or store an encrypted form of the pepper in persistent storage while the vault is locked. In contrast, the 2023 feature request envisions that users are prompted for the pepper when autofilling or copying passwords stored in the vault; the pepper would not be saved for later use.
Regarding what was just discussed before, I’m still curious how you @NoNameEntered envisioned this here: by “on same screen the master password is entered” did you mean when you log in to a BW app, or master password unlock, or master password re-prompt?
(… or maybe I just didn’t understand anything here )
IMO, the most likely interpretation is what I had written above:
If the idea is actually that the pepper should be entered in the same manner as the master password for items that have “reprompt” enabled, then the feature request here would indeed be equivalent to what was proposed in the earlier thread.
Regardless, I think that these implementation details are not sufficiently divergent to stand in the way of a thread merge…
Sorry for my wording. When I say Bitwarden I don’t mean the company, but the plugin in my browser.
I’m not claiming to know the technical internal working of BW so please ignore the wrong details.
Assume I open an account for this forum.
The password I chose is 123456.
BW stores it in an encrypted vault that’s protected with the master password.
That vault stored in the cloud.
Then there’s a data breach. Malware on my PC, vulnerability found in Bitwarden, master password leaked, etc
The attacker is now able to open the vault and export everything as plain text.
What does the attacker see then?
Password 123456
But that password is useless because it’s only part of the full password.
The other part is stored nowhere. Not on Bitwarden servers, not on my PC, not in the vault. It’s only in my memory/brain.
When I unlock the database the master password decrypts the database.
At the unlocking of the database I also enter the extra part of the password: abcde
When Bitwarden created the new login for the BitWarden forum the real password was 123456abcde, and not 123456 which is shown in the vault.
Bitwarden simply automatically adds abcde to every password entered or generated.
That means all passwords stored in the Bitwarden vault are incomplete and therefore useless.
So when Bitwaren logs in to a website it takes the password that’s stored in the vault, adds that extra password, and enters the combination as the login to the websiste.
That means:
A] If the user forgets the extra password the whole vault is useless.
B] If the user decides to change the extra password, all logins need to be changed.
But wouldn’t it be better if such an additional password that you suggest would be part of the encryption itself, because then – in theory – an attacker couldn’t decrypt anything with just the master password. (but would need the second password to even decrypt anything)
On the other hand, if you pepper just the passwords in BW login items, there’s a whole lot of information that wouldn’t be protected then (all additional information in notes fields/custom fields/authenticator keys/…, all cards/identities/notes [and they don’t even have a password field that would benefit from that], passkeys, attachments…). – And to e.g. just store a short PIN in the password field of a login item would always get the “pepper”… and if there still were any password fields on sites that only allow, let’s say 12 characters, that could also be complicated with a “static pepper” of a given length…
I think the only scenario in which your pepper idea would provide meaningful protection is if your local vault is locked with a weak PIN, and you have disabled “Require master password on restart” (or analogous scenarios when using biometric unlocking). In this case, an attacker who exfiltrates your local vault data while the vault is locked (encrypted) could brute-force the PIN to decrypt the vault.
Another thought just occurred to me (about practical implications): if you ever had to or want to change that suggested pepper here – for whatever reason --, it automatically would change all (peppered) passwords in login items, while obviously wouldn’t change the passwords on the sites. That would render autofill useless for most sites, until all sites are changed manually.
You decide to share your Disney+ streaming password with your brother. He now needs to know your pepper (“abcde”).
In exchange, your brother gives you his Netflix password. But, his pepper is “edcba”. To store it in your vault, you now need to change all your accounts to use “edcba”.
Your sister gets into the deal and shares her AppleTV+ password, but with pepper “abcxyz”. Now what? Do you and your brother now both change all your accounts to use “abcxyz”?
It seems like there would need to be a way to have different peppers on a per-account basis.
If you have not already done so, do read the link earlier shared, Pepper for your password | Bitwarden . The underlying concept of a “split password” is good. The only issue is forcing the same pepper on “all accounts”.
I think I’ll do that again… but just for the record: I don’t “doubt” peppering in general – I just have the impression that such an implementation in Bitwarden would make some things more complicated, and it doesn’t provide that much more security at the same time (at least not for all other data in the vault that is not a password field).
This is the proposal in the related feature request (Mot de passe combiné [Combined Password]) — Bitwarden would be agnostic, and simply prompt for a pepper each time a pepper-enabled password is autofilled.
)