The goal of DigestJ is to be as compliant as possible with a very specific aspect of RFC 2617 while supporting features above an beyond RFC 2617 to address its shortcomings with respect to vulnerabilities. Additionally, to provide a migration path away from the current state of relatively insecure password storage.

DigestJ provides a level of security to users because the user's password will never be sent to the server, even if registering an account with the server.

The Registration Process

• Registration requires a session.
• The server provides a salt to all unregistered users.
• The client produces a hash based on the salt (optionally, augmented with a client salt) and the user's password.
• A client salt protects from rogue servers providing the same salt for all accounts, effectively eliminating the salt and subjecting all hashes to dictionary attacks.
• The client requests an account by providing the username, hash and the client-side salt if used.

Differences between RFC 2617 and DigestJ

3.2.1 The WWW-Authenticate Response Header

• The scheme is different. Instead of "Digest", it's "DigestJ".

challenge = "DigestJ"

The reason for this is simply to circumvent the browser's digest implementation.

Available Feature Differentiations

• The algorithm can be changed to SHA256 instead of MD5.

Contrary to, seemingly, most implementations, MD5 is not the only supported algorithm for RFC 2617 compliant digest authentication. MD5 is simply the default, fallback algorithm. RFC 2617 does provide the ability to specify an algorithm which implies other algorithms can be used as long as the client and server both support it.

• Salt can be added which affects 3.2.2.2 A1 (Is this *-sess algorithm?)

A1 = digest(username ":" realm ":" digest(passwd ":" salt))

The salt can be chosen to be just about anything but once chosen, must always accompany the username, otherwise it effectively changes the user's password and becomes unrecoverable. A salt that includes a time component and some randomness might be an ideal solution as well as allowing the client and server to each contribute a portion of the salt.

Third-party Libraries

These were included in source until DigestJ v0.3.

Required third-party libraries:

• jQuery Core.
• MD5 and/or SHA256

It doesn't matter what MD5 or SHA256 algorithm is used, it only matters that the case of the file name and the function in the file correspond to the name used when configuring the session.