The article and comments don’t really answer the most important question here: Most modern hardware supports access to secure key storage via biometrics or pins that lock after a few attempts.
Is the issue that bitwarden fails to use these properly (e.g., by storing a short pin in the touch id enclave), or that the person reporting the bug is using a machine without such an enclave, and enabled pins anyway?
> Is the issue that bitwarden fails to use these properly
It's not so easy. Bitwarden runs in a browser on PC's. As far as I know, browsers don't provide a javascript API to the TPM. They probably supply a javascript API to their password store which may even be backed by a TPM (Firefox on Windows is I think), but they also allow you to browse their passwords while the browser is running so I wouldn't be keen on that.
Bitwarden also runs on Android. I haven't seen an Android TPM API. Instead Android supplies a "Keystore". It stores secrets that can be unlocked using phone managed secrets - like a PIN, fingerprint and so on. Yes, they have limited retries - but they come with the limitation that if you can unlock the phone, you can unlock Bitwarden. Not ideal - in fact pretty much the same situation as a browser, now I think about it.
So I suspect that while it's true "most modern hardware supports secure storage", the issue is Bitwarden doesn't run directly on the hardware. Instead it runs on platforms like Anroid or a browser that don't expose the hardware's secure storage directly.
Bitwarden has now a native app on PC.
I still use the browser extension but I might switch to the native app, as I reckon from other comments they do support OS security APIs
Is the issue that bitwarden fails to use these properly (e.g., by storing a short pin in the touch id enclave), or that the person reporting the bug is using a machine without such an enclave, and enabled pins anyway?