I have tried the argon2id kdf with 4 iteration, 1gb memory cost and 4 threads and it took more than 5s to unlock with the browser extension and slightly less with the android app.
Given that i already use LUKS with argon2id, 4 iteration, 4gb memory cost and 4 threads to encrypt my hard drive and the decryption take less than 3 seconds, it seems that the implementation of argon2id used by bitwarden is really slow.
Also using keepassxc, argon2id with the same parameters (4 iteration, 1gb, 4 threads) took less than 1 second.
The current implementation has room for improvements, but it is still limited by running in a browser.
The WebAssembly argon2 library has 2 issues right now:
It is single threaded (even with parallelism > 1)
It does not use simd instructions
For the latter, I have a pull-request open that makes use of SIMD. Once merged, it should cut unlock times by up to ~60% (depends).
Multithreading is also possible in WebAssembly, but requires significant changes to the used library. Given that the WebAssembly argon2 library is not actively maintained at the moment, that’s unlikely to happen anytime soon. In a test of mine this was about 10% of the unlock time compared to now (so <~0.5 seconds in your case), which is 10-20% slower than native.
Another option would be for browsers to natively implement argon2, which would be the best outcome.
For me I find using a middle ground is very effective. I have my KDF set at 5 iterations, 256 memory, concurrency 4 (although it isn’t supported fully yet) and the net outcome is about a 2-3 second login from scratch even while using a Yubi for two factor during the process.
5, 256, 4 is well above the default and puts up a pretty nice defense against brute forcing through!!