Yes, there's a challenge/response scheme (like in SRP), so the communication part is slightly improved, but what I'm talking about is that the server stores public key, and this public key is deterministically derived from password, thus stealing the database of public keys from the server is equal to stealing the database of password hashes (like in SRP).

I haven't read their code or critiques of it, so I can't say if that's the case for this algorithm.

But for this class of algorithms, that doesn't have to be the case. Starting with a cryptographic hash could keep the key from being reversed to the input. There are probably other things that could help as well, like maybe not using the password in the public key at all.

How exactly does "starting with a cryptographic hash" solve this problem?

Remember, the attack is: start with "aardvark", run the deterministic key-generation process, hash, scrypt, elliptic curve and all, and check to see if you get the same result. If you don't, move on to "apple", then "ataxia" and so on.

The attacker has every piece of information in the system except the password string, which they can substitute with a dictionary.

I haven't had a chance to look at the code yet, but riddle me this: Are they eschewing salts entirely?

Yes. The same [password,name,host] tuple should produce the same keypair.

It's not a question of reversing the hash, it's a question of what is the 'password validator' and what are the inputs to the algorithm which get you from 'candidate password' to 'compare result to the password validator and return true or false'.

Can you explain in more detail why you believe the public key "isn't the password" the way it is in a "hash based system"? I don't think this is true, but I'm not totally clear on what you're arguing.

Hey I got pulled away from this conversation and didn't continue.

In most systems where the server never sees your password, they store a hash that is generated from the password.

Then the login code on the client takes the password, performs the same operation and then sends either that same hash to the server, or one that's simple to calculate from it.

So if I steal your password file, I can log in as everybody without even knowing what their passwords are. I just change the code in the client to skip the hash generation part of the authentication algorithm and use the one I supply.

The idea with asymmetric ciphers (at least the ones that interest us) is that one party HAS to know the secret, and the other has no way to get it.

I'm even more confused now.

I think you're saying that this system is better because, since it uses public key pairs, an attacker who steals the password file doesn't know enough to log in as a different user.

Leaving aside that an attacker who steals your password file has probably mooted login security altogether, the attacker in this system seems to have exactly the same leverage as an attacker who steals a password file full of scrypt hashes.