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: Choosing a stronger password hash algorithm
Date Sun, 01 Jul 2012 19:48:54 GMT
On 6/29/2012 4:23 AM, Stefan Fritsch wrote:
> 
> Therefore I will go ahead and add bcrypt support to apr-util which 
> will be a big improvement for the 95% of users who don't need FIPS.

It sounds to me that after we spent a great deal of time to make APR
largely library agnostic, you are insisting on binding us to a specific
library.  I would be very hostile to that.

If you are talking about a plugable, client-agnostic approach which
the user can ignore the details of how apr was built, that would be
fine.

Before throwing code at APR, please post a patch, because the group
might largely be in agreement.  The delta to configure.in and the
headers is probably sufficient for now.  But if your solution is to
add more mandatory dependencies or make apr less flexible, it would
be met with resistance.

The user should remain largely oblivious whether the pw crypt used
lives in bcrypt or openssl or the kernel, and the resulting pw data
should be always portable between different builds of apr.  This was
the logic behind the sha1, md5 and other common password schemes.
The crypt scheme was an exception, one which can be resolved even
on win32 and hpux with the use of openssl's crypt implementation
or linking to fcrypt.

Platform or library binding dependent pw data takes us back to 1999.






Mime
View raw message