The website does a really poor job of emphasising that it's using asymmetric cryptography and some sort of challenge/response protocol, and how that is really where the improvement over the status quo is. It's _not_ just sending a hashed password.
I actually don't know very much about challenge/response protocols, and I'm struggling to find any good resources, so take this with a grain of salt. You could build a protocol out of digital signatures (probably there are massive things wrong with this, don't do this, here by dragons, don't build your own crypto etc. etc.):
1) When the user registers with the site, the client generates a public/private key pair and sends the public key to the server, which stores it.
2) When the user wants to log in, the server sends a challenge to the client. The client uses their private key to sign it and sends the signed message back to the server. The server uses the public key stored against the user to validate the signature.
Obviously this is more than just hashing the password on the client. If the server sends a different challenge each time (possibly time based like OTP?), you're protected against replay attacks.
The problem is you need a key pair. You don't want to generate a random one because then the user has to manage it and keep it with them and copy it from machine to machine etc. So the problem solved on the website is how to generate a good key pair from just a site identifier, username and password.
How effective it is at that, I have no idea.
[edit] other posts have helped me realise the public key is just an unconventially derived hash. Even if it's used in an unconventially way for authentication, you can brute force it the way you brute force any general hashing algorithm: key == generate_key(password_guess)
I'm still trying to figure this out but isn't it sending the ECDH of the private key which would be much longer then what the average user is going to use as a password (eg. I don't know, 1024 bit or something) and therefore more secure then sending a hashed password?
Edit: And then you (maybe?) use your password to encrypt the private key locally.. maybe? That's a total guess. That's what I'd do :P
I actually don't know very much about challenge/response protocols, and I'm struggling to find any good resources, so take this with a grain of salt. You could build a protocol out of digital signatures (probably there are massive things wrong with this, don't do this, here by dragons, don't build your own crypto etc. etc.):
1) When the user registers with the site, the client generates a public/private key pair and sends the public key to the server, which stores it.
2) When the user wants to log in, the server sends a challenge to the client. The client uses their private key to sign it and sends the signed message back to the server. The server uses the public key stored against the user to validate the signature.
Obviously this is more than just hashing the password on the client. If the server sends a different challenge each time (possibly time based like OTP?), you're protected against replay attacks.
The problem is you need a key pair. You don't want to generate a random one because then the user has to manage it and keep it with them and copy it from machine to machine etc. So the problem solved on the website is how to generate a good key pair from just a site identifier, username and password.
How effective it is at that, I have no idea.
[edit] other posts have helped me realise the public key is just an unconventially derived hash. Even if it's used in an unconventially way for authentication, you can brute force it the way you brute force any general hashing algorithm: key == generate_key(password_guess)