They could make the pin process intentionally slow… maybe with some number of iterations… and as computers get faster they can just update the number of iterations required…
If the PIN is local, only a secure element type of chip could meaningfully enforce this restriction. Otherwise, whatever memory or disk stores the secret encrypted only by the 4-digit PIN could still be brute forced. Just disabling entering a PIN in the UI would not be enough for security.
An Nvidia RTX 4090 can crack a 4 digit pin using PBKDF2 with 200k iterations in less than a quarter of a second. Argon2 is definitely the better option, but even at 1 hash per second, that's less 3 hours.
> [...] As a comparison baseline, a 2.4 GHz Core2 CPU can perform about 2.3 millions of elementary SHA-256 computations per second (with a single core), so this would imply, on that CPU, about 20000 rounds to achieve the "8 milliseconds" goal.
So you'll need something that takes at least as long as entering your full password, at which point you basically could enter the full password (from a UX perspective). They PIN is here to make it faster and it will always be security vs. ease-of-use.
It already is intentionally "slow". However, for a 4 digit pin there are only 10 thousand combinations. It is not practical for it to be so slow that 10000x it is an infeasible amount of time. Not only would the user have to way too long on each entry, the attacker could just use faster hardware.
Or multiple machines. There are about 31k seconds in a year. 3.1 seconds per iteration seems already slow as a response time to unlock a db so it's about one year for those 10000 attempts. Split it between 10 machines by first digit, it's down to a little more than one month. Split it between 100 machines by the first two digits and it's down to half a week.
A four digit PIN is poor security. What Bitwarden could do is removing that feature.
Split it to 5000 machines, which will be "quite easy to get" for a computation that takes a single line in most languages. Then we're talking about 6 seconds and 50% success on first try.
That's a bit like putting a website password check in the client-side JavaScript. Attacker removes lockout, continues brute-forcing.
There really isn't a solution if the entropy is low and the enforcement mechanisms are in the hands of the attacker. Even a TPM or secure element is just a financial obstacle to a sufficiently motivated attacker.
