Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden PINs can be brute-forced

ambiso.github.io

Post reply on HN
Print view View original

261–270 of 284 posts

Re: Bitwarden PINs can be brute-forced

#261

Post by lxgr »

TylerE wrote: post #214
eptcyka wrote: post #208

Earlier quoted context omitted.

When it comes to 4 or 6 digit pins, its almost impossible to ensure that no pin has been used before. At 8 digits, you might as well be using diceware anyway.

At least by not allowing 4 you get rid of the two most common lazy date formats (and YYYY)

Nothing prevents users from using 0YYYY or 0DDMM/0MMDD.

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.

Re: Bitwarden PINs can be brute-forced

#262

Post by lxgr »

eviks wrote: post #154
progbits wrote: post #140

Earlier quoted context omitted.

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.

It's not too small, your not limited to just numbers in your PIN on a computer

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.

Re: Bitwarden PINs can be brute-forced

#263

Post by munchbunny »

jve wrote: post #249
munchbunny wrote: post #234

Earlier quoted context omitted.

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?

> 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 g…

> How? I mean how can keylogger get the secret from which TOTPs are being generated?

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.

That said, just because they can’t steal your Yubikey’s private key, doesn’t mean they can’t take the bearer token from your computer. In general if your device is compromised it’s game over anyway.

Re: Bitwarden PINs can be brute-forced

#264

Post by lxgr »

beachy wrote: post #169
nabakin wrote: post #138

Earlier quoted context omitted.

You're assuming the average user understands security when that is definitely not the case. The job of Bitwarden is to help all users (even ones ignorant of security) to secure their data. If Bitwarden has no warning explaining that pins are unsecure, then the fault 100% lies with Bitwarden.

Some things fall into the "obvious" category, users should just know them, and it's not 100% on Bitwarden to make the world a safe place. Is it a good idea to leave your password on a piece of paper under your keyboard? No, and you shouldn't need Bitwarden to tell you that. Is it a good idea to use your name and date of birth as a password? No, and this should be obvious, not something Bitwarden needs to educate you…

> Some things fall into the "obvious" category, users should just know them, and it's not 100% on Bitwarden to make the world a safe place.

It‘s 100% their job to make passwords a safer system.

As an advanced user, I can look up whether the PIN is tangled to a server-side limit or a TPM (or equivalent) for maximum attempts enforcement.

Most users don‘t even know these things exist or how to look for them. That‘s arguably nothing they should have to worry about, though.

Re: Bitwarden PINs can be brute-forced

#265

Post by ziml77 »

I see many comments in here saying it's obvious that a PIN can be brute forced. But it is absolutely NOT obvious that's the case because for a long time now we've had hardware like TPM and Secure Enclave. With that hardware, you can have the database's key securely stored with the PIN being what lets the hardware release that key. And even if the attacker has physical access to the device, it can be protected from brute force by having the hardware forget the key after a number of failed attempts.

Re: Bitwarden PINs can be brute-forced

#266

Post by SiempreViernes »

lxgr wrote: post #259
andrewxdiamond wrote: post #162

Earlier quoted context omitted.

The user does not need to be aware of the threat model. 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

Not really: Consider e.g. a stolen laptop (without full-disk encryption or a screen lock). 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…

If you don't even have a screen lock on your laptop, what business do you have complaining that bitwarden didn't protect your secrets?

And it's not like there is much reason for any extra effort either, because that user will for sure be logged in to the webmail that they use for mail-2fa so all logins can be password reset anyway.

Re: Bitwarden PINs can be brute-forced

#267

Post by lxgr »

SiempreViernes wrote: post #266
lxgr wrote: post #259

Earlier quoted context omitted.

Not really: Consider e.g. a stolen laptop (without full-disk encryption or a screen lock). 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…

If you don't even have a screen lock on your laptop, what business do you have complaining that bitwarden didn't protect your secrets? And it's not like there is much reason for any extra effort either, because that user will for sure be logged in to the webmail that they use for mail-2fa so all logins can be password reset anyway.

Don't worry about me, I do have a screen lock.

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.

Re: Bitwarden PINs can be brute-forced

#268

Post by cryptonector »

monocasa wrote: post #218
cryptonector wrote: post #156

Earlier quoted context omitted.

You can encrypt sessions to the TPM. To do that you need to securely know a public key for the TPM. The protocol spoken to a TPM is like a micro-TLS. You get to encrypt, or not. You get to authenticate the TPM (like a server), or not. You get to do ephemeral-static key exchange (unlike TLS 1.3, which wants ephemeral-ephemeral key exchange). And you get to do PSK (password), and you get to do it in ways that are not s…

You can generally sniff the LPC bus to the TPM. Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it. https://pulsesecurity.co.nz/articles/TPM-sniffing But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.

> You can generally sniff the LPC bus to the TPM.

Yes, quite, which is why it's important to use encrypted sessions to the TPM.

> Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it.

They really really should.

> But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.

For something like bitlocker or bitwarden you really need the unlock step to happen so early in boot (or wake) that the only vulnerabilities present are those in the blessed firmwares and kernel that you're running. Once you have the OS fully booted the possibility of executing malicious code that intercepts the UI to the TPM is just too great indeed.

Re: Bitwarden PINs can be brute-forced

#269

Post by lxgr »

andrewaylett wrote: post #219
ddulaney wrote: post #198

Earlier quoted context omitted.

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…

Bitwarden's fingerprint integration does exactly the same.

Given that, really the only thing that Bitwarden would have needed to do is to clearly label the PIN feature as being much less secure than the biometry option, especially when used in combination with the "do not ask for passphrase after browser restarts" option, which persists an only PIN-encrypted version of the master encryption key to disk.

Re: Bitwarden PINs can be brute-forced

#270

Post by lxgr »

forty wrote: post #105

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 hope…

> 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/

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...

Post reply on HN