You are looking at historical revision 22209 of this page. It may differ significantly from its current revision.

crypt

This egg provides functions for generating secure password hashes.

This is done by providing Chicken bindings for the Unix crypt() function. It will attempt to use the system's crypt() for all available types, and supplies fallbacks when the native crypt does not implement a common scheme like Niels Provos' bcrypt() or Ulrich Drepper's SHA-2 based crypt().

Basic usage

Basic usage is extremely simple (just like Unix crypt()):

Generating a new password hash

This will automatically use the hashing mechanism currently deemed most secure. At the moment that is the Blowfish hashing scheme with 2^12 rounds. A new random salt is automatically generated each time this procedure is invoked with only one argument.

Checking whether a password matches a hash

This is done just like Unix crypt() by checking whether the generated hash matches the input hash:

Why use crypt()?

The advantage of Unix crypt() over other password hashing schemes is that crypt() provides a way to upgrade the hashing mechanism to a more secure one without having to rehash all passwords; hashes are stored with a prefix code which indicates the hashing mechanism used to generate that hash, so they continue to work using the old algorithm while newly generated hashes are hashed using the stronger algorithm.

Other languages might include just a library specifically for bcrypt(), but this egg's author thinks it is silly to provide a separate library with a dedicated API, precisely because crypt() is designed to transparently upgrade to stronger algorithms as time progresses. bcrypt(), because it is adaptive for CPU speed improvements, will provide good security for the foreseeable future as long as no weaknesses are discovered in the algorithm itself. Once that happens (or a substantially better scheme is developed, etc) you would need to replace all calls to that library with a new one (or change bcrypt() to include whatevercrypt() code).

Background info

Crypt hashes come in three basic flavors:

Raw DES

rEK1ecacw.7.c (salt: re)

This is just a raw base64-encoded DES password hash. The first two characters encode the salt, the rest is the hashed password.

Extended DES

Extended DES uses a variable number of encryption rounds and 24 bits of salt rather than 12 bits.

_J9..K0AyUubDrfOgO4s (salt: _J9..K0Ay)

The leading underscore indicates we're using the extended DES scheme here. The first four characters after the underscore indicate the number of iterations to run the encryption algorithm, the next four represent the salt and the final eleven are the hashed password.

The ALG encodes the algorithm used for generating the hash, the ALGSPECIFIC is usually the salt followed by the hash. Some schemes store some additional settings before the salt, and some separate the salt from the hash with a dollar sign.

Currently, the following values for ALG are standardized:

$1$

Paul Hennig-Kamp's MD5 scheme. This is a very baroque system, introduced in FreeBSD, which runs MD5 for a large but fixed number of iterations on the password.

$2a$

Niels Provos' Blowfish scheme. This is an adaptable scheme introduced in OpenBSD, which allows the system administrator to determine the number of rounds to run the algorithm. As hardware speed improves, this number can be increased to compensate.

$5$

Ulrich Drepper's SHA-256 scheme. This is also an adaptable scheme, introduced in glibc.

$6$

Ulrich Drepper's SHA-512 scheme. Same as the above, except with hashes of double the size :)

There are also some less common values:

$apr1$

Identical to $1$. This prefix is generated by the Apache Portable Runtime library (used by htpasswd, for example)

{SHA}

SHA-1 hash, also used by the Apache Portable Runtime library. (yes, this is not compatible with the standard dollar-sign prefix. Apparently these guys like being completely incompatible to the rest of the world)