0

I'm looking at using SCRAM for authentication of clients of the server I'm writing, as SCRAM does not send password over the wire in a way that it is useful if intercepted, and does not store credentials in the server.

However, one thing I am not sure about is how to setup a new user with a password in my server without transmitting the password to the server.

My current theory is that, when setting up a new user, I can precompute the salted password on the client, and send that to the server (over TLS), the server then stores that and uses it to authenticate clients over SCRAM.

As I understand it, if the salted password is compromised along with the username that does not allow a malicious user to use it to authenticate via SCRAM, as SCRAM includes a challenge response.

Does this seem like a sensible approach?

1 Answer 1

0

No, this isn't a secure approach.

Knowing the SaltedPassword does allow an attacker to impersonate the client, because they can trivially calculate the ClientKey, the StoredKey and then the ClientProof for each challenge.

Note the definitions from, e.g., RFC 5802:

ClientKey       := HMAC(SaltedPassword, "Client Key")
StoredKey       := H(ClientKey)
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof     := ClientKey XOR ClientSignature

You should only transmit the StoredKey and the precalculated ServerKey – which is HMAC(SaltedPassword, "Server Key") – to the server.

2
  • Thanks, that makes sense. Presumably I'd also have to transmit the salt itself, and number of iterations too? As they are also used by the server when authenticating. Commented Aug 18 at 7:27
  • @user2610356: Yes, the salt and number of iterations must be transmitted to the server as well.
    – Ja1024
    Commented Aug 18 at 15:39

You must log in to answer this question.

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