Is it possible to implement a login protocol with asymmetric cryptography instead of the hashed password method?

For example, while creating an account, the client generates a private/public key pair from a hash of the username, password and other additional data. The public key is then sent to the server with the username, and the server stores the username and the public key. When the user wants to login, he enters his password, the client regenerates the private key, signs a nonce with it, and sends the signed message to the server. The server is then able to authenticate the user as he knows the public key associated with the username.

Is there any flaws in this protocol?

And what would be the advantages over storing the password hash?

EDIT: I actually found a quite complete answer here: https://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase?rq=1

  • So if all you need for the privkey to generate is just the password, how is it safer than using password-only? Attackers can still try to guess the password to get the correct privkey and then log in. I think you want to take a look at certificate-based authentication. May 20, 2016 at 10:26
  • Using a regular password hash is much simpler and more secure. May 20, 2016 at 10:39
  • @MaximilianGerhardt Okay I see, I though the fact that the password never leaves the client, and is not stored on the server could be more secure. But if the password is weak, everything else will be.
    – lmeunier
    May 20, 2016 at 10:53
  • I'm not aware of any asymmetric cipher where the keypair is functionally derived from a datum (but I suppose it could be used to apply distortion to an elliptical curve). What method do you propose for the algorithm?
    – symcbean
    May 20, 2016 at 11:04
  • @symcbean I was thinking about generating a 256 bit hash from the user data and using this as the private key of a EdDSA curve.
    – lmeunier
    May 20, 2016 at 12:15

1 Answer 1


It is a bad idea to generate the key for asymmetric cryptography totally on predictable data (i.e. user chosen password) instead of secure random data. By basing the key completely on predictable data the key gets the same predictability as the password used as input.

Still, asymmetric cryptography can be used for authentication/login but not in the way you propose. Typical examples are authentication with client certificates in TLS and authentication with a key in SSH. In both cases either the public key is known by the server (and associated with the user) or the server can derive trust to the certificate by building the trust chain to locally trusted issuer certificates.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .