Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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 for authentication).


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.


Sorry if it came across as a statement directed at you as a person lxgr, I was using "you" in the generalised sense:

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


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?


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

I assumed if someone can install something on my computer, I'm toast.


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


I see private key within Yubikey the same as TOTP secret. Ok, for TOTP it is stored on host, but as you said: "you don’t need to know the secret"

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.


> When I press button on yubikey, it pastes some jibberish - way more than 6 chars, but can't THAT token be re-used?

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.


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


The remediation is human and pw/pin policy: make sure users pick a good pin and that they're not using it anywhere else.


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.


Does it matter if you can bruteforce a 4 digit pin in a day, if there's no TPM guarding it?


A PIN is almost by definition a low-entropy secret and is only secure together with some rate-limiting mechanism.

Never (only) encrypt things with a PIN.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: