I think that's the problem here: Bitwarden hashes the passwords on the client side but it runs on various client devices, some more powerful than others, and others not able to run efficient Argon2 implementations.
Ah, I thought it's a JS library used on a server side. But am I correct that they still pass the derived master-key to server side in a plain form?
Citing the OP:
>Sure, you might tolerate a longer unlock time, but is the security gain really worth the cost to your battery?
I think the battery concern is over-blown. How often do you login into a service? I think that for typical use-cases, amortized battery-cost of a login is negligible. And for other use-cases you can let users choose.
The issue is that if an attacker can eavesdrop on a compromised authentication server, then it can record user's master-key and thus he will be able to impersonate user without issues until the password gets changed (i.e. the derived master-password is actually plays role of a password now). With PAKE this issue simply does not exist.
Via the master-key, the program derives(locally) the key to encrypted the data and a different secondary key for authentication against the server. without knowing the master-key you can't decrypt the vault even if you were able to trick the server into sending you the vault.
> some more powerful than others, and others not able to run efficient Argon2 implementations.
Like what? It looks like personally my phone is 4x slower than my desktop. So if I calibrate for one or two seconds on my phone, the security should be pretty acceptable. Do I need to worry about devices much slower than that?
Try srspass.com which runs argon2id in the browser. Takes about 3 seconds on my ARM phones for the unlock, which uses quite heavy argon2id parameters, above the recommended memory and iterations.
I don't think a 3s wait for a session, for greater security, and that on an unoptimized device is going to be breaking UX.
How? Seriously interested. This is cross-plattform software. How do you change that from PBKDF2-SHA256 to Argon in a way that still lets you use your desktop PC as well as your 4 year old budget Android device? And then support user configuration on top of that? Same about raising iterations.
The submitted github comment also makes that point, this is actually hard to do.
As someone who worked in this field. Offering "options" when a vast majority of the user base don't even understand that their data is encrypted, is often a poor approach to take.
Users will forget their Master Passwords even and because they forgot them they will believe they've been "hacked" and blame you.
Users on Hacker News and similar sites where users actually understand the underlying technology to some degree are the exception, not the norm. Adding options does not help a vast majority of the user base and it complicates your codebase further. Imagine making that change and less than 1% of your users actually use that feature?
Agreed, defaults are the norm and then the advanced settings are layered. Even so, explaining and showing the differences visually or with video is possible. I don't agree with treating people as babies when it comes to tech.
Citing the OP:
>Sure, you might tolerate a longer unlock time, but is the security gain really worth the cost to your battery?
I think the battery concern is over-blown. How often do you login into a service? I think that for typical use-cases, amortized battery-cost of a login is negligible. And for other use-cases you can let users choose.