The state of the art for SASL is SCRAM-SHA-1. It uses challenge/response authentication and it allows the server and the client to only store salted hashes (using PBKDF2 with a configurable number of rounds). It also uses mutual authentication (the server also proves to the client that it has the hashed password, not just the other way around).

No idea how that compares to TFA, because they have no documentation.

Yeah, there are plenty of authentication systems out there for this kind of thing, and preferably something like SRP would be used.

And before SRP there was EKE. I thought the main reason it never saw wider use was because it was patented. Although according to Wikipedia, those patents expired in 2011 and 2013.

Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. IMO the current state of things is better than it would be with 1000s of random websites with DBs full of clear-text passwords.

Nah. Hashes of hashes works just fine, and allows the actual password value to never be stored plaintext. A simple example:

Stored on server: x = SHA256("mypassword")

Server challenge to client: send a secure random nonce

Client sends: c = HMACSHA256(nonce, SHA256("mypassword"))

Server verifies: c == HMACSHA256(nonce, x)

In some implementations, the server challenge and 'c' are encrypted using 'x' or some derivation that both sides can create. In addition, salts can remove the sensitivity of the stored 'x' values (https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...)

The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem.

This only mitigates knowing the password itself, not anything to do with authentication.

> The problem with hashes of hashes is now instead of the password being directly grabbed, the hash is directly grabbed, which can be thrown through the challenge-response system with no problem.

But now you have to grab the hash first from one of the endpoints, MITMing the connection no longer suffices to impersonate the user.

I suppose public key schemes would be preferable, but deploying those isn't feasible for a lot of use cases.

> Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes.

Do they? Doesn't the server just need to share the salt and algorithm parameters it stores anyway?

The server can store the salt and parameters, although it gets really hairy if you decide that MD5 is too weak and now you want to upgrade to SHA-1 or SHA-256.

Good question. This would be even better.