No subject
Tue Nov 29 10:43:08 WST 2011
-m Use Apache's modified MD5 algorithm for passwords.
Passwords encrypted with this algorithm are
transportable to any platform (Windows, Unix, BeOS,
et cetera) running Apache 1.3.9 or later. On
Windows and TPF, this flag is the default.
-d Use crypt() encryption for passwords. The default
on all platforms but Windows and TPF. Though
possibly supported by htpasswd onm all platforms,
it is not supported by the apache server on Windows
and TPF.
-s Use SHA encryption for passwords. Faciliates
migration from/to Netscape servers using the LDAP
Directory Interchange Format (ldif).
Basically, what this means is that you can create passwords hashed by
one of three algorithms. If you use '-m' then it uses an MD5 based
hash. If you use '-s' then it uses SHA1. These are both fairly
standard hash functions and, although the Apache implementation will
doubtless add its own bits and pieces (e.g., salt), by the sounds of
things they're both fairly portable.
The final option is to use the crypt() library function which is
basically the same hashing algorithm used for user's login passwords on
the system. Although from my quick skim of the manual page I can't find
this stated, I have a feeling that this is the default algorithm so if
you've just been using htpasswd without either of the other command line
options then your passwords are probably hashed with this.
Now, I'm almost 100% positive that Apache includes some information at
the start of the hash in the password file that identifies which hash
was used (the same way as in /etc/shadow). What this means is that it
shouldn't just randomly fail if one of the different hash algorithms
mentioned above has been used since the program can tell how the
password was hashed and automatically use the correct algorithm.
Now I'm no Apache guru so all I can offer you is a hunch but all of the
above seem to point to one main conclusion. You created the hashed
passwords on one system using the crypt() hash. It all worked. Then
you took it to a new system and now they don't. Very likely the old
system and the new system had different crypt() algorithms. Newer Linux
systems tend to default to using an MD5-based crypt() instead of a
DES-based one. Therefore my guess would be that the previous (older)
system used the traditional DES crypt() while the newer one uses MD5.
So therefore when the new system tries to hash the supplied user
password it is hashing it using MD5 and then comparing this against
(presumably) the same value hashed with the Unix DES crypt(). Obviously
the two won't match...
The only real solution would be to configure the new system to use the
older DES-based crypt(). This means that user passwords on the system
will be restricted to 8 characters or less and will be slightly easier
to break using a dictionary attack. Otherwise it should be business as
usual. You can change the system's crypt() algorithm either by editing
/etc/login.defs and disabling MD5_CRYPT_ENAB or editing /etc/pam.d/login
and removing the reference to 'md5' in the password entry.
Of course, it could easily be something completely different... I'm
assuming you've checked other things like the versions of the server
software etc. Also, try adding a new user to your htpasswd file and see
if you can log in as this user. Also, compare the first part of the
password hash for the new user against the older users. For memory the
part of the hash between the $'s identifies the hashing algorithm used.
Hope this helps,
Christian.
--
DSA 0x0EC1D28C: BBCB 0D79 4EBB 078A A066 7267 8BED E9D6 0EC1 D28C
More information about the plug
mailing list