apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apr_password_validate on win32 silently mishandles crypted hashes
Date Thu, 27 May 2004 02:05:44 GMT
rbb@rkbloom.net wrote:
> On Wed, 26 May 2004, Stas Bekman wrote:
>>rbb@rkbloom.net wrote:
>>>Portable doesn't mean what most people think in means in APR.  It means
>>>the code _should_ work on all platforms.  It doesn't mean that the data
>>>will be processed identically on all platforms hwoever.  In this case, you
>>>are asking windows to validate a password that it can't encrypt.  That
>>>isn't going to work.
>>And according to you definition it is not portable. Since it _should_ work,
>>but it doesn't.
> Nope, it shouldn't work, and it doesn't.  You are passing a crypt()
> encrypted password to a function that, on Windows, doesn't understand
> crypt.  APR doesn't mean that all platforms will support all possible
> data.  In this case, APR on windows can't process crypt() encrypted
> passwords.

I understand all that.

>>>What we do in this case, is apr_password_validate uses either crypt, md5,
>>>or base64, depending on the input.  There should be a function in APR to
>>>encrypt passwords (not sure if there is, and I can't find one in a quick
>>>But, do not expect that the details will work cross-platform, just the
>>In which case the code doing crypt verification doesn't belong to
>>apr_password_validate. A quick grep of the Apache source shows that it's only
>>used by the Apache support utils and should be moved there verbatim.
> APR isn't just Apache anymore.  This API exists and may be in use by other
> projects using APR.

I doubt they do so for that particular feature of apr_password_validate, since 
it is not crossplatform.

>>If you want to support crypt, include the implementation of fcrypt() on those
>>platforms that don't carry crypt.
> We have discussed including a crypt implementation in the past and
> rejected it, but I don't really remember why.  I think the problem here,
> is that we have different ideas of what is desired.  I don't have any
> desire to support crypt().  We support crypt() for backwards compatibility
> for Apache, but that doesn't mean that our goal is to support crypt.

Sure, that's reasonable.

>>At the moment apr_password_validate is half-baked API with very vague docs.
> I'm sorry, but that just isn't true.  The API isn't half-baked at all.  It
> just doesn't work the way you expect it to work. 

I don't expect anything at all, all I'm doing is writing tests to exercises 
API, albeit in Perl and the documentation of the Perl users of the APR API. 
I'm trying to look at the C docs and hope that I won't need to dig into the 
source code. I have to write tests and docs for a way too many functions to 
learn by heart how everything works. My real problem is that I can't test 
things on all platforms, as I develop on linux. And when everything seems to 
work perfectly, I get a bug report telling me that on windows it doesn't work.

 > As for the docs, yes they could probably use some work.

I've posted the following wording:

  * Validate hashes created by APR-supported algorithms: md5 and base64.
  * hashes created by crypt are supported only on platforms that provide
  * crypt(3), so don't rely on that function unless you know that your
  * application will be run only on platforms that support it.
  * @param passwd The password to validate
  * @param hash The password to validate against

Is that good enough?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message