Posted on by admin

SCRAM: a new protocol for password authentication

In today’s world, a secure authentication mechanism for web sites is an absolute necessity.  Hackers and script kiddies love to hijack accounts in any way possible.  While it’s impossible to completely prevent a man in the middle access attack, utilizing SCRAM will certainly make it exponentially more difficult.  For a site that isn’t running e-commerce, I believe this is a much more cost-effective solution to an SSL certificate. SCRAM (Salted Challenge Response Authentication Mechanism) is a new protocol and data storage mechanism to support password based authentication. SCRAM addresses a number of important security issues that are not dealt with by existing mechanisms, in a manner that can be cleanly deployed and widely implemented.

SCRAM is a SASL (Simple Authentication and Security Layer) mechanism, which means that it can be used with any standardized protocol that uses SASL, including XMPP client/server protocol, LDAP, SMTP, POP and IMAP. The basic concept of SCRAM is that the client and server never send enough information for a hacker to simply decrypt (or use rainbow tables) the password.  Instead, a ‘client proof’  is generated that the server uses to determine authentication.

The SCRAM authentication process works like this:

    1. Client sends username and ClientNonce
      1. The client stores its own request string in memory for later use
    2. Server sends salt, ClientNonceServerNonce, and iterations
      1. The server stores the client request and its own in SESSION for later use
      2. The client stores the server request in memory for later use.
      3. The client uses the iterations response to determine the strength of the hash
    3. Client performs the calculations necessary to form a ClientProof, sending it and a ClientNonceServerNonce to the server
      1. The server verifies the ClientNonceServerNonce with the one stored in SESSION
      2. The server performs the calculations necessary to get a ClientSignature
      3. The server obtains the ClientKey by performing an XOR on ClientSignature and ClientProof
      4. The server hashes the SaltedPassword using the iterations provided in step 2
      5. If the passwords match, an HTTP 200 response is sent with a URL to use on page refresh. If the passwords don’t match, an HTTP 401 response is sent

A good example can be found on 4sak3n Design.

Leave a Reply