Scripted Authentication Using Netscape Directory Server
Suppose we’re using the Netscape
Directory Server. It stores passwords in one of three ways: as
cleartext, encrypted with the Unix crypt( )
function, or encrypted using S
ecure Hash Algorithm
(SHA). Here’s how the server represents an
SHA-encrypted password as an attribute of a user object:
{SHA}W8r/fyL/UzygmbNAjq2HbA67qac=The gobbledygook after {SHA} is another
Base64-encoded value. It decodes to a 20-byte SHA hash. We can
extract that value in hexadecimal form like this:
use MIME::Base64;
print unpack('H*', decode_base64('W8r/fyL/UzygmbNAjq2HbA67qac='));The result is `5bcaff7f22ff533ca099b3408ead876c0ebba9a7',
which is the hexadecimal representation of the SHA hash value of the
password open sesame.
Like Unix’s crypt( ), SHA is a one-way
hashing function. When you assign a password in Directory Server, it
applies the one-way hash to the cleartext password to produce an
encrypted password, which it stores in a user object in the
directory. When a browser, mailreader, or newsreader tries to
authenticate to a Directory Server-based application—such as
Netscape’s web, mail or news server—the sequence of
events is as follows:
- The client sends a name and password to the provider of the service it’s requesting.
We’ll call this provider the application server, to distinguish it from the directory server. This client-to-application-server connection can be a cleartext channel or it can be SSL-encrypted. In either case the application ...