[plug] Apache & htpasswd
Christian
christian at amnet.net.au
Mon May 21 11:53:53 WST 2001
On Mon, May 21, 2001 at 11:26:10AM +0800, Brian Tombleson wrote:
> > 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.
>
> The /etc/shadow does include information at the start of the password
> string, presumably a reference to the encryption algorithm. Unfortunately,
> the current apache htpasswd file does not, although it can when you change
> algorithm via the switches.
Looking at the information you've posted below it definitely looks like
Apache *is* including this information at the start of the hash although
for DES crypt()'s it appears not to so this suggests DES crypt() is
the default.
> Password Entry from the old schema (majority in this format)
> junior:jutt65bRqol9h9SQRsNR5aX/
This is a weird one. See below.
> A different one from old schema (some in this format):
> test1:4Ot32i2AbtEQo
This looks like a normal DES crypt().
> New one added with -m param
> testing:$apr1$f8039/..$uXy6ZEf8z9m7OCZDxVVME.
The '$apr1$' is indicative of MD5.
> New one added with -s param
> testing:{SHA}GvF+c3IdvgxAARuC7Uuxp9vjzik=
Ditto for {SHA} I would say.
> New one added with -d param
> testing:6P/OqUAOM4ykY
This is the same sort of hash as 'test1' above.
> New one added with no htpasswd params.
> testing:LMevUHwLm/bOw
Ditto.
However, looking at the hash for 'junior' above it seems to be using
something completely different! My guess is that both 'testing' entries
and 'test1' are using standard DES-crypt(). The 'junior' entry though
is something weird by the looks of things.
> >From this and looking at man 3 crypt (".. encrypted password .. a series
> of 13 printable ASCII characters .."), I'd say that the current system is
> using the system's crypt() routine by default and the old system was at one
> stage using the same and then changed to the alternative 3DES encryption.
> It also means that changing to MD5 or SHA isn't the answer. What a mess :(
First point is that it's not encryption, it's hashing. (This is actually
somewhat important.) Second is, what makes you think 3DES is involved?
Obviously 3DES could be used to generate hashes in the same way pretty
much all block ciphers can be but I don't remember ever hearing of it
being used in this way at all.
> <snip assuming MD5 - which it's not>
>
> > 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.
>
> Hmm .. well, there's no references in /etc/login.defs appropriate, and
> /etc/pam.d/login seems to externalize the authentication config to
> /etc/pam.d/system-auth.
Ok, here is the entry from my /etc/pam.d/login file:
password required pam_unix.so md5 nullok obscure min=4 max=8
The 'md5' bit means to use MD5. Which distribution are you using btw?
(The above is Debian).
The fact that you don't have 'md5' in your line means that perhaps the
problem is actually *opposite* to what I suggested before. Maybe your
old system was using the MD5-based crypt() (this might explain the
longer hashes, e.g., for 'junior') but some other hashes in the file
were DES-based crypt() hashes. Very likely htpasswd does not detect
which crypt() algorithm the system is using since it probably assumes
that it will never change. From the config files you posted it *seems*
like your new system isn't using an MD5 crypt() at all. (You could
confirm this by posting one of the hashes from your /etc/shadow file
although obviously you may not want to do this! Perhaps just post part
of it or scramble the last few bytes of it slightly.)
If this is the case then maybe adding 'md5' to the PAM file above will
help... It's probably worth a try anyway!
> If I add a new user to this htpasswd file, they authorize correctly - ie.
> correct password allows, incorrect password fails.
>
> So what I think I need is the same version of crypt() (or compile apache
> with this mechabism) that is configurable to generate 24-character encrypted
> password strings instead of the 13-character that it currently is.
> I have alooked through all the compile options in apache and can't find
> anything related to this apart from switching to MD5 - which is not a
> solution.
If I'm right then this isn't an Apache issue. Apache doesn't really
know what sort of crypt() the system is using and it just calls the
library function and uses the results. If you're using the latest
version of Apache then this is really all that you can do.
--
DSA 0x0EC1D28C: BBCB 0D79 4EBB 078A A066 7267 8BED E9D6 0EC1 D28C
More information about the plug
mailing list