Today, I will be showing you a mechanism to not only secure the passwords being held in your databases, but a way to secure the authentication process itself from prying eyes.  Enter SCRAM.  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

SCRAM is a relatively new protocol for authentication written under RFC 5802 that works very well with web technologies as they are today.  It is algorithm agnostic, protocol agnostic (for the most part), and straightforward to implement.  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.  If you wish to know more about it, feel free to read the links above.

Differences

There are some key differences in the SCRAM-SHA256-JSON approach we will be utilizing today:

1. The protocol is HTTP, so some bits of the protocol are no longer necessary/possible.
2. In lieu of an AuthMessage, a JSON object is sent back and forth.  This is possible because the RFC defines the order of each part included in an AuthMessage.
3. The ‘third phase’, where client verifies server authentication has been left out to reduce client-side overhead.
4. A smaller iteration was chosen to cut the impact on performance caused by JavaScript code.
5. Input passwords will be hashed before salting.

I tried to stay as true to the protocol as possible, however some things just didn’t make sense in a web environment where connections do not persist and encryption transparent to the code itself.  None of the authentication steps have changed, just the way they are sent.

The Code

This tutorial is broken up into two major sections, the server-side and client side.  I will talk about what needs to happen on each step and present you with the well commented and completed source code.

Overview

I think it will be necessary to outline what we are actually trying to do in each section.   The SCRAM authentication process works like this:

1. Client sends username and ClientNonce.
    a. The client stores its own request string in memory for later use.
2. Server sends salt, ClientNonceServerNonce, and iterations.
    a. The server stores the client request and its own in SESSION
       for later use.
    b. The client stores the server request in memory for later use.
    c. 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.
    a. The server verifies the ClientNonceServerNonce with the one
       stored in SESSION.
    b. The server performs the calculations necessary to get a
       ClientSignature.
    c. The server obtains the ClientKey by performing an XOR on
       ClientSignature and ClientProof.
    d. The server hashes the SaltedPassword using the iterations
       provided in step 2.
    e. 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.

Technologies Used

You should not need to install additional PHP extensions, however, mcrypt is highly recommended if you don’t already have it.  You might also want to pickup mbstring (if you don’t already have it).  A minimum PHP version of 5.2 is required to run the provided code.  It can certainly run on older versions with some effort, but PHP 5.3 is becoming the norm, so get with the program!

The client side will use the Dojo Toolkit’s core libraries for element manipulation and prototyping.  There isn’t much Dojo-specific code in the provided file, so it will be easy to remove if you so choose.  On the other hand, Crypto-JS is definitely engrained within the client side code.  Crypto-JS can be custom compiled using Google’s Closure Compiler if need be, which makes it an extremely small library to include.