7 ms·

Of course the PIN can be brute forced. It feels like reporting "I can walk over the lawn fence". That PIN is probably here to prevent your kids from messing wit

by forty 4y ago

Of course the PIN can be brute forced. It feels like reporting "I can walk over the lawn fence". That PIN is probably here to prevent your kids from messing with your vault when you grab your coffee with your computer unlocked. 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/ https://signal.org/blog/secure-value-recovery/

_8j50 4y ago
Ugh..no it does not work that way. 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.
- forty 4y ago
  I agree with the mindset and that's why I think it's good the data is still encrypted even if, as the author mentioned, they might as well have left the data in plaintext. 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.
  - _8j50 4y ago
    If it is not the default behavior then I agree with you.
    - aidenn0 4y ago
      I've been using bitwarden for years and didn't know this feature existed, so it at least wasn't the default in the past.
    - flxy 4y ago
      This is not the default behaviour and it has to be enabled per client/platform. The first unlock after a reboot still requires the master password as well.
- femto113 4y ago
  There really needs to be another standard class of vulnerability besides "physical access to the device" along the lines of "access to a copy of the on disk data". There are so many paths to this and some never required physical access or even an accidental exposure on the part of the user, it could be a breach of a provider (ala LastPass).
asveikau 4y ago
They could make it take more time to derive a key from a pin. That would make it more difficult to brute force.
- progbits 4y ago
  The pin space is just too small. What's the longest an user is willing to wait? 10 seconds? 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.
  - eviks 4y ago
    It's not too small, your not limited to just numbers in your PIN on a computer
    - lxgr 4y ago
      A PIN is, if not by definition then by practical user experience, a short, numeric secret. You really can‘t blame users for using one for a field that purports to ask for a PIN.
      - eviks 4y ago
        Except this thread isn't about blaming the users, but assessing the potential for improvement, where this simple mistake leads to inaction So yeah, they should change the stupid name and be more clear that users should use letters as well, but it's still valuable to increase argon work factor parameters
        lxgr 4y ago
        If you call something a PIN, salted hashing is completely pointless (and software still doing it tells me that the vendor hasn't grasped this fact). 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.
deleted 4y ago
[deleted]
nabakin 4y ago
> Of course the PIN can be brute forced. 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.
- teekert 4y ago
  I always wonder, with a keylogger on my device, I’m probably more f-ed using my master password all the time, right? Isn’t that a large threat? Larger than the one from op?
  - munchbunny 4y ago
    Yes, with a keylogger watching you you’re typically pretty f-ed. Though that’s also one of the reasons using a physical FIDO token as a second factor is a good idea, since the keylogger isn’t going to be able to steal your private key off the hardware token, unlike for TOTP. 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?
    - jve 4y ago
      > since the keylogger isn’t going to be able to steal your private key off the hardware token, unlike for TOTP 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.
      - zinekeller 4y ago
        Assuming that they're the standard SHA-1/30sec TOTP and the keylogger is smart enough to store it, at least two 6-digit codes and their approximate time (https://www.unix-ninja.com/p/attacking_google_authenticator https://www.unix-ninja.com/p/attacking_google_authenticator).
jeremyjh 4y ago
It’s one thing to offer a pin for quick unlocks, and quite another to allow that pin to be the only key required to unencrypted the files stored on the disk. A pin should only secure the master key in memory; it should not even be possible to write passwords to disk with such weak encryption.
foobiekr 4y ago
FDE doesn't matter at all since a running system is going to have the volume mounted. 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.
ar9av 4y ago
Bitwarden argues that the finding is out of scope because from what I can gather the claim that exploiting this requires access to the device. If that were the case, I'd agree with them. But having access to the Bitwarden database is not the same as having access to the device. There are plenty of vulnerabilities that give you limited read access. Simply selling your hard drive without erasing the data first would be a very common scenario. 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.
- ddulaney 4y ago
  I really like the way 1Password and MacOS work together for security [0]. 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-mac/ https://support.1password.com/touch-id-apple-watch-security-...
  - KennyBlanken 4y ago
    KeepassXC does the same thing. Once you enter your password, you can unlock with your fingerprint.
  - andrewaylett 4y ago
    Bitwarden's fingerprint integration does exactly the same.
mcronce 4y ago
I agree with you. Short PINs are for preventing well-intentioned people from accidentally using the wrong account (which I do consider quite valuable, for the record) - not for keeping bad actors out.
d1lanka 4y ago
Where’s my KeePassXC gang at.
senectus1 4y ago
It would not be a terrible idea for the pin to "expire" if tried more than "x" times unsuccessfully in a row, defaulting back to the master password.
- jdmichal 4y ago
  The Bitwarden client does this. The issue is that nothing prevents the attacker from taking the encrypted database and working with it directly, thereby bypassing that client protection.
abrookewood 4y ago
That was my initial reaction as well, but it isn't necessarily true. If you read up on how Windows Hello uses a PIN, then it becomes clear that they can be pretty secure where: (1) a PIN is tied to the device; (2) a PIN is local to the device; and (3) a PIN is backed by hardware. https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password https://learn.microsoft.com/en-us/windows/security/identity-...
chrismorgan 4y ago
> Of course the PIN can be brute forced. 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.
ambiso 4y ago
> Of course the PIN can be brute forced. It feels like reporting "I can walk over the lawn fence". 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 https://imgur.com/a/jj9FveF
MomoXenosaga 4y ago
Any code can be brute forced if you have a century to spare and enough computing to throw at it. Which is why my bank card is blocked after three failed attempts.
lxgr 4y ago
> 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/ https://signal.org/blog/secure-value-recovery/ 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 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-backups/ https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee...

by forty 4y ago

_8j50 4y ago

Ugh..no it does not work that way. 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.

forty 4y ago
I agree with the mindset and that's why I think it's good the data is still encrypted even if, as the author mentioned, they might as well have left the data in plaintext. 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.
- _8j50 4y ago
  If it is not the default behavior then I agree with you.
  - aidenn0 4y ago
    I've been using bitwarden for years and didn't know this feature existed, so it at least wasn't the default in the past.
  - flxy 4y ago
    This is not the default behaviour and it has to be enabled per client/platform. The first unlock after a reboot still requires the master password as well.
femto113 4y ago
There really needs to be another standard class of vulnerability besides "physical access to the device" along the lines of "access to a copy of the on disk data". There are so many paths to this and some never required physical access or even an accidental exposure on the part of the user, it could be a breach of a provider (ala LastPass).

asveikau 4y ago

They could make it take more time to derive a key from a pin. That would make it more difficult to brute force.

progbits 4y ago
The pin space is just too small. What's the longest an user is willing to wait? 10 seconds? 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.
- eviks 4y ago
  It's not too small, your not limited to just numbers in your PIN on a computer
  - lxgr 4y ago
    A PIN is, if not by definition then by practical user experience, a short, numeric secret. You really can‘t blame users for using one for a field that purports to ask for a PIN.
    - eviks 4y ago
      Except this thread isn't about blaming the users, but assessing the potential for improvement, where this simple mistake leads to inaction So yeah, they should change the stupid name and be more clear that users should use letters as well, but it's still valuable to increase argon work factor parameters
      - lxgr 4y ago
        If you call something a PIN, salted hashing is completely pointless (and software still doing it tells me that the vendor hasn't grasped this fact). 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.

deleted 4y ago

[deleted]

nabakin 4y ago

> Of course the PIN can be brute forced. 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.

teekert 4y ago
I always wonder, with a keylogger on my device, I’m probably more f-ed using my master password all the time, right? Isn’t that a large threat? Larger than the one from op?
- munchbunny 4y ago
  Yes, with a keylogger watching you you’re typically pretty f-ed. Though that’s also one of the reasons using a physical FIDO token as a second factor is a good idea, since the keylogger isn’t going to be able to steal your private key off the hardware token, unlike for TOTP. 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?
  - jve 4y ago
    > since the keylogger isn’t going to be able to steal your private key off the hardware token, unlike for TOTP 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.
    - zinekeller 4y ago
      Assuming that they're the standard SHA-1/30sec TOTP and the keylogger is smart enough to store it, at least two 6-digit codes and their approximate time (https://www.unix-ninja.com/p/attacking_google_authenticator https://www.unix-ninja.com/p/attacking_google_authenticator).

jeremyjh 4y ago

It’s one thing to offer a pin for quick unlocks, and quite another to allow that pin to be the only key required to unencrypted the files stored on the disk. A pin should only secure the master key in memory; it should not even be possible to write passwords to disk with such weak encryption.

foobiekr 4y ago

FDE doesn't matter at all since a running system is going to have the volume mounted. 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.

ar9av 4y ago

Bitwarden argues that the finding is out of scope because from what I can gather the claim that exploiting this requires access to the device. If that were the case, I'd agree with them. But having access to the Bitwarden database is not the same as having access to the device. There are plenty of vulnerabilities that give you limited read access. Simply selling your hard drive without erasing the data first would be a very common scenario. 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.

ddulaney 4y ago
I really like the way 1Password and MacOS work together for security [0]. 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-mac/ https://support.1password.com/touch-id-apple-watch-security-...
- KennyBlanken 4y ago
  KeepassXC does the same thing. Once you enter your password, you can unlock with your fingerprint.
- andrewaylett 4y ago
  Bitwarden's fingerprint integration does exactly the same.

mcronce 4y ago

I agree with you. Short PINs are for preventing well-intentioned people from accidentally using the wrong account (which I do consider quite valuable, for the record) - not for keeping bad actors out.

d1lanka 4y ago

Where’s my KeePassXC gang at.

senectus1 4y ago

It would not be a terrible idea for the pin to "expire" if tried more than "x" times unsuccessfully in a row, defaulting back to the master password.

jdmichal 4y ago
The Bitwarden client does this. The issue is that nothing prevents the attacker from taking the encrypted database and working with it directly, thereby bypassing that client protection.

abrookewood 4y ago

That was my initial reaction as well, but it isn't necessarily true. If you read up on how Windows Hello uses a PIN, then it becomes clear that they can be pretty secure where: (1) a PIN is tied to the device; (2) a PIN is local to the device; and (3) a PIN is backed by hardware. https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password https://learn.microsoft.com/en-us/windows/security/identity-...

chrismorgan 4y ago

> Of course the PIN can be brute forced. 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.

ambiso 4y ago

> Of course the PIN can be brute forced. It feels like reporting "I can walk over the lawn fence". 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 https://imgur.com/a/jj9FveF

MomoXenosaga 4y ago

Any code can be brute forced if you have a century to spare and enough computing to throw at it. Which is why my bank card is blocked after three failed attempts.

lxgr 4y ago

> 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/ https://signal.org/blog/secure-value-recovery/ 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 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-backups/ https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee...