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:
- Client sends username and ClientNonce
- The client stores its own request string in memory for later use
- Server sends salt, ClientNonceServerNonce, and iterations
- The server stores the client request and its own in SESSION for later use
- The client stores the server request in memory for later use.
- The client uses the iterations response to determine the strength of the hash
- Client performs the calculations necessary to form a ClientProof, sending it and a ClientNonceServerNonce to the server
- The server verifies the ClientNonceServerNonce with the one stored in SESSION
- The server performs the calculations necessary to get a ClientSignature
- The server obtains the ClientKey by performing an XOR on ClientSignature and ClientProof
- The server hashes the SaltedPassword using the iterations provided in step 2
- 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.