[dchest]

(Not my service, I'm just a random commenter)

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.

[fuoqi]

>The same happens with PAKE during registration, where the user will need to provide the verifier.

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.

[dchest]

Right, the verifier can't be used to impersonate the user, but can be used to verify password guesses offline.