Adding a unique short string of characters to all passwords locally (protection if bitwarden is hacked)
Feature function
This feature will allow advanced users to add a short string of characters (let’s say 2 or 4 letters as an example) that the bitwarden client will add automatically to all passwords when auto-filling.
The password would be the combination of the password stored in bitwarden servers and the 2 or 4 characters stored locally in client
The objective of this functionally is add an additional layer of security in case Bitwarden is hacked and the users vault is compromised (like lastpass)
This additional characters would be stored locally in client and never synced with bitwarden servers.
User would have to remember this 2 to 4 characters (in addition to the master password) and input them only once when downloading or updating a new client.
This would be an optional feature, designed for users concerned with a eventual hack to Bitwarden servers (as I am!)
Related topics + references
Are there any related topics that may help explain the need and function of this feature?
Are there any references to this feature or function on other platforms that may be helpful?
The idea of split your password into 2 parts - the one stored in the password manager, the other stored in your head (aka horcrux in Harry Potter) is old and already described in a beautiful article: https://kaizoku.dev/double-blind-passwords-aka-horcruxing.
I don’t know if it is a good idea that
the password should be the combination of the password stored in bitwarden servers and the 2 or 4 characters stored locally in client
In any case, Bitwarden clients / extensions should be able to save and update on the server only the first N character of a password and the user should be able to configure the number of character N to be added at the head or at the end of each password.
So another option can be to let the user remember the short string of characters (let’s say 2 or 4 letters as an example) in his head or to store 2 or 4 letters in Bitwarden.
This seems to be a variation of the “secret key”/“keyfile” idea used by other password managers, which has already been requested.
The main difference being that the feature requested here is to use the locally stored secret when logging in to the accounts stored in the vault, whereas the existing feature request uses the locally stored secret when logging in to Bitwarden itself.
@moremoresp — you referenced the Lastpass breach, but your proposed feature is not useful unless you have a weak (crackable) master password. And someone with the resources to crack your master password would probably also be able to brute-force the 2-4 character pepper that must be added to the passwords that they now have access to.
Hi, IMHO any attacker robbing some millions passwords, would probably test them in batch, discard those not working and concentrate in those that work. Any small addition to a robbed password would be probably enough for the attacker to discard it.
Well, attackers are not stupid, and if your feature request is implemented, then they will be well aware that Bitwarden users have the option of adding this locally stored pepper to their login passwords. If the setting is optional, it would also be simple to confirm whether a vault has this setting enabled or not.
So, if an attacker has already successfully cracked your vault master password, and knows that the only thing standing between them and access to your bank accounts is a 2-4 character code, do you really think they will stop there?
But then the attacker would have to brute force the website they want access to… and presumably, the website owner (a bank in this example) would limit login attempts and (hopefully) alert the account owner of suspicious activity.
Obviously, encryption and a strong master password is the first line of defense in any breach, but if implemented securely this would be a good second layer… and I’m for any any implementation that’s a net positive to security.
I will say this, I love the idea of the horcrux method but in all reality, this is absolutely one of the easiest ways to hack a login, let me explain.
From a cybersecurity standpoint and my knowledge if I were to somehow gain access to your password manager and lets say the website is Instagram and somehow I have the username horcrux versions of your password and lets say you even have the totp enabled.
If I were to input that password into lets say ‘john the ripper’ algorithm and few other methods i would input the password that it has especially if i know you use a horcrux style password then i would let it figure out the remaining portion. If you are adding lets say 5 charcters it still abides by password length requirements since I only need to figure out 5 charcters that are added you understand?
With that said, I do like the idea if the password happens to be ‘x’ amount of length and only a portion missing is still a significant amount that needs to be figured out then it would be more of a challenge. But think of it like this, if I were to tell you hey my password for my password is xyz but you wont guess the remaining portion missing, well now i have upper hand by that. Overall a stronger master password would easily fix this.
Your method requires the same pepper to be added to every password, so the attacker could start by attacking accounts for low-value websites (which may not even implement any rate-limiting), and just go on to attack a different account if any rate limiting is encountered.
Thanks for sharing your point of view!
I am not an expert at all. My guess is that when there is a major security security breach , the attacker gets access to several millions passwords. It’s not easy to manage that amount of information with a deadline…so I guess that the attacker will prioritize those that work straight forward.
And in any case, I don’t really see the downside: another extra security layer with very little hassle for the user.
Isn’t that good?
You’re not wrong… nothing is 100% effective. But if stuff isn’t implemented because it’s not 100% effective, nothing will ever be implemented.
I just don’t see a downside from a security standpoint. There might be a downside from a usability and functional standpoint, but not if it’s a optional setting.
At the very least, I think it should be a part of the discussion… maybe a feature like this can be evolved into something more effective… maybe an algorithm that randomly selects the peppered addition that’s stored client side… if that’s even possible from a developer standpoint.
The security breach that matters for the purposes of this discussion would be a breach of Bitwarden’s servers. Bitwarden had 100,000 registered users in 2018, so assuming 50% annual growth since then, a successful heist would net approximately 500,000 encrypted vaults.
These would then have to be cracked, whether by brute force, social engineering, or spear phishing. Those vaults whose owners have set master passwords that are weak or re-used will be the first to fall, but even those will require some effort to crack. Because of the time and effort needed to find a poorly guarded vault, including the time and effort to go through the cracking process (which is only semi-automated), I believe that once a master password has been successfully cracked, special attention will be paid to extracting maximum value from the breached vault. That is why I don’t think it would be any significant effort to brute-force a 2-4 digit code compared to the effort that was required to get in to the vault in the first place.
I think that your idea of a locally stored pepper would potentially be useful for protecting against master password leaks (by shoulder surfing, inadvertent disclosure, etc.), but I don’t think it would be very helpful for protecting against a breach of Bitwarden’s servers. The concept of a secret key or keyfile (as used by 1Password and KeePass) would be a more effective prophylactic against a server breach.
Of course, the best protection is a strong master password.
