Avoid passwords. "A secret is something you tell one other person, so I'm telling you". If possible adjust APIs to not rely on knowledge of secrets for their functioning, and then this entire problem evaporates. e.g. WebAuthn.
If it's crucial that a human memorable secret (a password) is used, choose an asymmetrical Password Authenticated Key Exchange in which it's possible for the relying party to learn a value with which they can confirm that the other party knows the password, but never learn what that password is. This is really difficult to do properly, OPAQUE is the current recommendation of the IETF for this purpose.
Only fall back to hashing passwords because you're obliged to for legacy reasons.
PAKEs bring little to the table when looked at in context of an actual threat model[1], meanwhile they add a fair degree of complexity and their implementations are much less battle-tested. Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up.
Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords".
> Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords".
It seems like you've no idea how WebAuthn works, or why it's such an important improvement. That's fine, but probably better to just tell people "I know nothing about this" rather than pretend to know enough to give a recommendation.
> PAKEs bring little to the table when looked at in context of an actual threat model
The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed.
WebAuthn can be used with or without a password. You said "avoid passwords", and mentioned WebAuthn. I simply clarified "don't avoid passwords with WebAuthn". By all means use WebAuthn, but ideally keep the password, too.
> The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed.
You have correctly deduced that my comment on PAKEs was a response to your comment on PAKEs and not a criticism of WebAuthn. I believe I can say with confidence that we both think WebAuthn is great.
> By all means use WebAuthn, but ideally keep the password, too.
WebAuthn is perfectly capable of delivering two factor authentication in a single, easier to use, more secure solution. Passwords are awful, it's yet another indictment of our industry that somehow yet again a temporary hack was enshrined as a great idea. See also: people are still making new programming languages with Hoare's Billion Dollar Mistake.
If you've got WebAuthn plus a password it's like you used a padlock to secure your gate, but for some reason you also tied it shut with a shoelace. I am not going to be intimidated by the need to untie the shoelace if I've somehow broken the padlock, yet even if I can't break the padlock I can easily steal the shoelace anyway. Sites which have password + WebAuthn are secured by WebAuthn, but the user's passwords are as vulnerable as ever (to phishing, to database exposure, logging screw-ups, and so on).
The reason you might do that is legacy again, but I'm not talking about "What people might be obliged to do for legacy reasons" rather what they should strive for.
> Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up.
The main benefit of PAKE is avoiding accidental logging of passwords, which absolutely happens at organizations all the time. ZKP is a fine approach, although you can avoid much of the issue with something simpler (addressing a narrower threat, but the most relevant piece).
If it's crucial that a human memorable secret (a password) is used, choose an asymmetrical Password Authenticated Key Exchange in which it's possible for the relying party to learn a value with which they can confirm that the other party knows the password, but never learn what that password is. This is really difficult to do properly, OPAQUE is the current recommendation of the IETF for this purpose.
Only fall back to hashing passwords because you're obliged to for legacy reasons.