> 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