0

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

Community
  • 1
lmeunier
  • 1
  • 3
  • 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. – Maximilian Gerhardt May 20 '16 at 10:26
  • Using a regular password hash is much simpler and more secure. – user1751825 May 20 '16 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 '16 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 '16 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 '16 at 12:15
  • Cryptography is hard. Don't try to be clever and re-invent the wheel. – Little Code May 20 '16 at 13:53
  • @LittleCode The phrase you heard, and are repeating, is about encryption algorithms, not about protocols. Plus, I'm not trying to re-invent the wheel, I think this protocol could enable more functionalities. But as explained, it is true that predictable data is not well suited for asymmetric cryptography. – lmeunier May 20 '16 at 21:42
  • @lmeunier, you are reinventing the wheel, for the reasons Steffen Ullrich told you, and he also pointed out it's been done before with SSH and TLS, so you are basically trying to re-invent SSH/TLS. – Little Code May 20 '16 at 21:46
  • @LittleCode The main point of my question was to know why such a scheme wasn't implemented to handle user login, as it is successfully used in application like bitcoin, ssh or tls. It is not rare to see a website hacked and the password disclosed, so I think it is normal to ask if there could be better ways. I am by no way re inventing the wheel, I would have to invent something first. – lmeunier May 20 '16 at 21:55
  • Ya might want to checkout Mnfst which has server and client applications source code on GitHub. From what I've read it uses public keys and signed messages from a clients post date and if the sig checks out, then the message is accepted by the server. No user name or password other than the key's (the privet bits of which stay local) are used so it simplifies login considerably. The test domain seems to have gone down & the code doesn't seem to be maintained anymore but it's still the closest project to what you'll likely want to implement for sign-in. – S0AndS0 Oct 28 '16 at 18:57

1 Answers1

2

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.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465