[0]: https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
As for Bitwarden's implementation: it doesn't send the password to the server, it sends, basically, a PBKDF2 hash, which is different from the one used for encryption. The leaked hash can't be used to decrypt the database unless it's bruteforced. However, the protocol is not ideal, there's a weakness that I wrote about here: https://dchest.com/2020/05/25/improving-storage-of-password-...
AFAIK, 1Password uses SRP with PBKDF2 for verifier.
No, there is an important difference: leaking this verifier does not let an attacker to impersonate user at will. See my other message [0].
Is my understanding correct that you derive two keys from user password, one used for authentication and one for decrypting encrypted content which does not leave the user's computer? In that case, yes, it's somewhat better than the typical scenario, though I personally would still prefer if a proper PAKE was used for authentication. It may not apply to your service, but leaking encrypted data can still result in exposing certain meta-information, which may be important, so it's better to be extra-safe in such matters.
When retrieving the vault, the program will generate the secondary key, provides it to the server(You can add 2FA btw), the server sees that indeed it matches one of the ID's and sends you back the encrypted vault. decryption is done locally.
I don't see any issue with this process, maybe you care to point the attack vector\scenario
You can add 2FA to the authentication process.
All metadata is obviously encrypted, the data is just a single blob. you maybe could try to guess the number of entries based on size but that's too dynamic as well.
These products were attacked before, decrypting the vault wasn't how they were attacked.
It was with bugs\vulnerabilities within the browser extensions that lead to data leaks. something else entirely.
The same happens with PAKE during registration, where the user will need to provide the verifier. Since everything happens over TLS anyway, and hopefully, with pinning (in apps), this is not a huge concern.
I haven't checked Bitwarden, but even though 1Password uses SRP, the initial registration happens in a browser. (PAKE inside a browser with JavaScript is even more useless.) Their protocol though uses a strong key in addition to password, making password bruteforcing from the verifier impossible.
I'm not against PAKE — the biggest benefit is that you don't have to create your own protocol and make mistakes. What I'm saying is that for such use cases its security benefits compared to other protocols are negligible.
In a typical PAKE, generated challenge depends on random values generated by both server and user, so if at least one of them is not controlled by an attacker, the generated challenge will be different each time. So leaking the verifier or eavesdropping on previous logins does not help an attacker to impersonate user in any way.
The submitted github comment also makes that point, this is actually hard to do.
Choice is always better. for people who care\worry, they can change to something more resistant to cracking.
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?
You're thinking wrong.
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.
I don't see any issues with that.
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.
The vault is decrypted locally
No. Master key doesn't leave client machine, only its hash is transmitted over the network. See dchest's link above.
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?
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.