You are thinking in hypotheticals like many developers do.
Most infostealer malware just exfiltratr your data and disappear before being detected do they can hit a lot of targets before commom av starts detecting them. People also accidentally disclose data, back it up on a usb drive and lose that drive, have their pc stolen,etc...
If you have keepass2 with a memory argon2 and a password/passphrase none of that is a concern.
Yes, the malware could also be a keylogger/RAT and you'd be screwed then. One the most important security mindsets to have is "perfection is the enemy of good", specific security controls exist to address specific threats/risk not to address arbitrary and and an unbounded number of possible threats.
Sure entering a passphrase each time is better for security. But if the user chooses to set up a PIN instead, I feel the current behavior is reasonable.
> This brute-force will very likely be successful, since PINs are usually very low-entropy. Now, granted, the key derivation function is PBKDF2 with 100000 iterations (+ HKDF), but that won't help with a 4 digit pin.
It would be better to not have that feature at all, that convenience feature goes a bit too far. But nice to see that's the only thing they found, I'm sure they looked for more severe issues but found none.
You could argue a security product shouldn't let folks set a PIN due to footguns like this and instead require something like WebAuthn for an "easier" login method.
Times 10k that is just 27 hours. Spend a couple of bucks on a few beefy EC2 instances and you crack that in an hour or two.
A Personal Identification Number typically has 10k (or less frequently a million) possible values. Hashing buys you a few seconds of brute force resistance here at most, which is completely useless.
If you dial up the hashing complexity enough to make a dent, even legitimate logins will start having an unacceptable UX and battery life impact. You're just on the wrong side of the e function with PINs.
> be more clear that users should use letters as well
The entire point of the feature is that the PIN, whether letters or numbers, is shorter and/or easier to type than your passphrase. If you require users to use something of equivalent security to their passphrase, you might as well remove the feature.
Your last point is also misleading - no, you don't require the equivalent to master password, and yes, it still makes sense in that case. "Shorter/easier" can still mean enough entropy for the smaller threat model of local compromise (with even more entropy required in the master password for the bigger threat of cloud compromise). It's when it drops down to the level of literal 4-number PIN, then it becomes useless against this threat and only useful for an even smaller threat
This is obvious to those that know anything about security, but it is not obvious to the average user. It is Bitwarden's job to keep the user safe within their platform and if they provide a pin option, the average user knows no better than to use it. If Bitwarden does not explain how insecure pins are, then the fault 100% lies with them. Blaming the user is rarely ever an effective or useful argument.
OPs point was the pin isn’t protecting much at all because it doesn’t really need to. The user isn’t making a risky decision, because if the attacker gets as far as _being able to put the pin in_, the whole thing is toast regardless of guessing the pin or not
If Bitwarden could somehow implement the PIN attempt counter in secure hardware or on their server, they could achieve something more resistant against local offline brute force attacks.
A Yubikey could do the trick, theoretically (but unfortunately the FIDO API does not really lend itself to encryption, as it was designed only for authentication).
Still, I think that software in general, and security software in particular, should follow the principle of least surprise.
In the case of PINs, this is, in my view, an implicit contract to rate-limit invalid PIN attempts somewhere, regardless of all other security measures.
> We can use one, you or we when we are making generalisations and not referring to any one person in particular. When used like this, one, you and we can include the speaker or writer
https://dictionary.cambridge.org/grammar/british-grammar/pro...
Though that also begs the question, if I can get a keylogger onto your device, why wouldn’t I try to implant something slightly more capable?
How? I mean how can keylogger get the secret from which TOTPs are being generated?
And why wouldn't some other malware won't be able to read whatever data hardware token inputs? I'm myself yubikey user and would like to know in what ways it is more secure than TOTP, even in the scenario when my workstation gets compromised.
I assumed if someone can install something on my computer, I'm toast.
Since it’s time based with a 30 second window, you don’t need to know the secret, you just need to be able to repeat the code as it is typed. It takes more effort because it has to be done in real time, but 30-ish seconds is pretty doable.
> And why wouldn't some other malware won't be able to read whatever data hardware token inputs? I'm myself yubikey user and would like to know in what ways it is more secure than TOTP, even in the scenario when my workstation gets compromised.
The way (most) hardware tokens work, including the Yubikey, the private key is generated on the key and it never leaves the key. When the FIDO challenge/response happens, you relay the server’s challenge to the Yubikeu, it does the private key operation with the onboard chip, and sends back the response for you to relay back to the server. Done this way, your computer never needs to know the private key, but you can still prove you physically own it, which is what the server is trying to verify.
When I press button on yubikey, it pastes some jibberish - way more than 6 chars, but can't THAT token be re-used?
Okay, browsers have some integrations with this stuff so it is not always some kind of a web form where that goes into, so could be a bit more secure.
I'm no security expert, I'm just thinking out loud and hoping someone educate me :)
Yeah, the end result (whatever header value or cookie in browser) is still readable by malware.
Just to be clear, that's not related to FIDO which I was originally talking about. That's one of the extra OTP features that most Yubikeys come with, but it's unrelated to the Yubikey's FIDO capability.
Every time some site ridiculously insists I "use a more secure password", I sigh and add "A1!$" to the end of my 32-character alphanumeric random string.
Never (only) encrypt things with a PIN.
Secure boot also doesn't matter because the boot time root kits are a rarity and trojaned downloaded SW (npm, homebrew, etc. nearly completely unprotected from malicious actors beyond the bare minimum) or the massive browser attack surface are what are actually used.
What would be nice is proper layered sandboxing at the OS level, always on, but obviously the kernel-userland ABI is not actually very secure in practice, and has been the source of recurring escapes. But at least it would be something.
Consider this: as it is, sophisticated users on, say, the MacOS platform, who download SW such as homebrew, youtube-dl, whatever, or do local development with npm and other package managers, are actually in a much worse place than unsophisticated users who run with "only from the app store" enabled.
This is not a good place to be.
That's why SSH keys or GPG keys are typically protected by a pass phrase. Not a PIN, not a password, a pass phrase. At least that's the wording that OpenSSH uses, and Bitwarden should do the same. Secure your database with a pass phrase, not a PIN, or else you might be vulnerable. That's how it should be communicated to the user. These details matter.
Even if my laptop is unlocked, each 1Password interaction needs my fingerprint. That unlocks a secret stored in the Secure Enclave, which I trust. (Security is hard and flaws are possible, but Apple has done a reasonably good job here from what I can tell.) I only have to mess around with typing a long string of nonsense in when I'm registering a new device, rather than every time I want to use my SSH or GPG key (or trusting an agent to hold it in memory, which... I'll do it, but I won't like it).
I wish I could rely on similar things from Linux, but the user experience just isn't there on the desktop. A previous employer issued laptops that had both a fingerprint reader and some kind of HSM, so the hardware was there, but I remember both of them missing drivers at the time, and even with drivers the userland software support would've been very hacky.
[0]: https://support.1password.com/touch-id-apple-watch-security-...
When you enable the PIN, you deliberately weaken your security for convenience. However, when the database unloads, your database is still protected by your pass phrase.
This is not the case if you disable the "lock with master password on restart" option. In that case only your PIN is guarding access the the vault data.
Using a PIN shouldn't have to mean weakening the security, since there's several secure implementation options of a PIN. (See other comments about Windows Hello for example)
https://learn.microsoft.com/en-us/windows/security/identity-...
There’s no “of course” about it. Every place I can think of having used a PIN in the last decade has not been susceptible to brute-force attacks, due to the PIN being stored off-site (e.g. payment card) or in a TPM (e.g. Windows Hello), and a few incorrect attempts triggering blocking of the payment card or PIN or whatever.
If you think carefully about the description of this specific feature, and where and how it’s running, then yes, you’ll probably realise that the PIN will be brute-forceable. But people are probably used to the idea that PINs actually aren’t susceptible to this kind of attack.
This is entirely non-obvious: there's several ways to implement a PIN unlock in a secure way (see e.g. what you mentioned about Signal and other comments about e.g. Windows Hello). Bitwarden chose an insecure one and to not warn about its risk in the clients (unlike some other features, where you get a big modal warning when enabling them; see the end of this comment).
> Protecting from a real attacker with access to your unlocked computer is a bit hopeless (as someone mentioned, they probably can install some key logger and steal the master password and everything else later).
This is a different attack scenario. If I throw away my computer, or you steal it in its powered off state, a keylogger won't help you since I won't be entering my password again.
> Protecting from an attacker with your laptop locked should be done at the OS level with FDE and secure boot.
Definitely, FDE and secure boot would mitigate the attack (if your computer is off). However it's still not enabled by default on most systems and Bitwarden recognizes that since they give you a big modal warning that your encryption key will be stored in plain, if you set the lock option to "Never": https://imgur.com/a/jj9FveF
Which is why my bank card is blocked after three failed attempts.
You could do that, but you should definitely also design this in a way that does not fail catastrophically if the server-side enclave fails, which at least Intel's version seems to have a habit of doing every couple of months or years.
A nice way would be to use a modern PAKE that can recover a client-side secret securely after a successful authentcation, such as OPAQUE: https://eprint.iacr.org/2018/163.pdf
Conceptually, you do a PAKE, and upon successful authentication deliver server-side stored entropy to the client (either through the PAKE, if it supports the feature natively such as OPAQUE, or explicitly over an encrypted channel secured under the PAKE-derived session key), which then combines it with client-side stored entropy to decrypt the database. That way, the server can rate-limit the client's PIN entry attempts, but does not have access to the vault itself even if it learns/brute forces the PIN.
Facebook uses a combination of this and the HSM/enclave approach for encrypted WhatsApp backups (although without the client-side stored secret, since the use case is recovering from a lost device, not protecting data on a compromised device): https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee...
Protecting from an attacker with your laptop locked should be done at the OS level with FDE and secure boot. Protecting from a real attacker with access to your unlocked computer is a bit hopeless (as someone mentioned, they probably can install some key logger and steal the master password and everything else later).
It never hurts to be clear on the threat model (And they should probably go with the option 1. suggested by the author), but I feel in that case the behavior matches reasonable expectations and the author is a bit of bad faith.
For solution 2. if you want to check a pin server side without trivial access to the PIN from the server you can do it à la signal using secure enclaves https://signal.org/blog/secure-value-recovery/