4

Is it safe to use ECDH for challenge-response authentication, with server key being ephemeral?

The goal is that server does not store sensitive data (hashes) and allow clients to use additional security if needed (for example generate and store their key in a smartcard and skip key derivation).

  • Client derives private key from the password, using a strong hash algorithm (similar to bitcoin address generators using passwords)
  • Server generates a key and sends its (ephemeral) public key and a challenge string
  • Client must reply with the challenge, encrypted with the shared key
  • Server checks if decrypting response yields the challenge

Assumptions

  • A secure channel is already established
  • Server has the client's public key stored
iovoid
  • 143
  • 6

3 Answers3

1

Client derives private key from the password, using a strong hash algorithm
Server has the client's public key stored

So the server has a hash of the password. This defeats your goal that the server wouldn't have a password hash. All you've done is making your own password hashing function.

A password hash is any value derived deterministically from the password (and a salt, unless you're doing it wrong). Adding a step of private-key-to-public-key calculation into the password hash calculation is just that: adding a step. It's not a particularly useful step: if it was, standard password hashing functions would do it. Since every private key maps to a different public key, it isn't a harmful step in itself, but it doesn't help with security.

Your description of the protocol is missing a step where the server has a salt stored (generated randomly when the password was set) and sends this to the client as part of the challenge. If you don't use a salt, your scheme is vulnerable to rainbow tables, which make cracking multiple passwords stored with the same hash algorithm much more efficient.

There is no way to avoid storing a password hash on the server. How else would the server know that the client knows the password? It needs to have enough information to distinguish the correct password from other inputs. And this is exactly the information that an attacker needs to carry out a brute force password search. The best you can do for password authentication is to make this brute force search as hard as possible. Your proposed scheme doesn't help with that.

If the client has a (strong, randomly generated, and hence impossible to memorize by a normal human) secret value in addition to the password, then it's possible to devise a scheme where the server cannot reconstruct the password even by brute force. (I will not venture to spell out such a scheme in this answer.)

Gilles 'SO- stop being evil'
  • 20,442
  • 4
  • 54
  • 97
0

Here’s a link that shows how to implement ECDH with long term public keys and ephemeral shared keys. You could just add this authentication after the TLS handshake as it’s own layer. Think about the openID protocol. You can publish the keys at a well-known-endpoint, it’s not necessary to wrap them in a certificate.

Modal Nest
  • 1,473
  • 5
  • 18
Ryan Dines
  • 101
-2

First off, generating an asymmetric key pair is an expensive operation. As you might know, it is done once (usually while creating a certificate signing request) and used for multiple sessions. Web servers usually use it for a year (check the expiry date of say google.com's certificate)

Servers are typically designed to handle multiple requests from clients and one of the metrics of the quality of the server is to see how much it scales to burst client requests.

If you're talking about one asymmetric key pair per client, it's a huge ask, let alone one key pair per session. Apart from computation power, you need to consider the entropy concerns too. i.e., is my server capable of generating enough high quality randomness to cater all key pair generations?

Having said all this, let's assume you're infact using ephemeral assymetric key pairs. Thing is, you can use them for challenge-response verification as well! Which is what most of the standard protocols do. Once the certificates are exchanged and their signatures are verified, the proof of possession of private key is done using challenge response. To prove A has the right private key, B will encrypt a random string using A's public key and send it to A. A decrypts that using it's private key and sends back the random string in plain text which B verifies. Same thing is done with roles exchanged to prove B has the right private key of its key pair.

If you really want to do the authentication part using ECDH, you can't because

  1. ECDH has a random component in it hence cannot be mapped to a static password.
  2. Any two parties can derive a symmetric key using ECDH. There is no way to tell if you're exchanging keys with the right guy. The authenticity of the keyex parties must be ensured before the keyex is initiated.

Therefore, I would say No, ECDH will not serve your requirement of "server not holding the client's password but still is able to authenticate client".

commanderdileep
  • 1