apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_password_validate on win32 silently mishandles crypted hashes
Date Thu, 27 May 2004 18:40:30 GMT
At 07:34 AM 5/27/2004, Geoffrey Young wrote:

>> I beg your pardon, gentlemen. Would you be so kind to decide first
>> between yourself whether this is a bug or not? According to Ryan it's
>> not a bug, according to your comment above, Bill, it is.
>while I've been up most of the night, so I might not be thinking clearly, it
>seems as though if someone were to move a unix-generated crypt .htpasswd
>file to win32, 

Whoa - nobody every promised file compatibility, only functionality
on the same machine.  That is not a problem.  In apache 2.0 we
went to md5 hashes for *exactly* this reason, across all platforms,
by default.

Even Un*x'es don't have consistent implementations of crypt()!!!
Some are 16 and some are 32 bit seeds, etc.

The @bug should not say "Win32 yadda yadda" - but it should
spell out that different platforms will support different password
storage formats.

>mod_auth's call to apr_password_validate would end up simply
>comparing the two values for equality.

That's wrong, IIRC we test md5's/sha1 first (???).  If you want to
drop support for plaintext storage in APR 1.0 - I'd strongly back
that move.


>  meaning that passing the actual hash
>as cleartext would succeed.  at least that's what I see when I boil down the
>APU_DECLARE(apr_status_t) apr_password_validate(const char *passwd,
>                                                const char *hash)
>    else {
>        /*
>         * It's not our algorithm, so feed it to crypt() if possible.
>         */
>#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
>        apr_cpystrn(sample, passwd, sizeof(sample) - 1);
>    return (strcmp(sample, hash) == 0) ? APR_SUCCESS : APR_EMISMATCH;

View raw message