apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Choosing a stronger password hash algorithm
Date Sun, 24 Jun 2012 08:34:17 GMT
On Sunday 24 June 2012, Graham Leggett wrote:
> On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote:
> > Openssl is not required, neither for apr nor for httpd. I propose
> > to import either crypt_blowfish or scrypt into apr, just like
> > apr contains some foreign sha1 and md5 code. This way we would
> > not get an additional external dependency.
> 
> APR-util has a crypto library to deal with this exact problem - the
> need for low level crypto functions without having to tightly bind
> ourselves to one toolkit over another, or import code. With the
> formal move by the Redhat people towards NSS as a shared crypto
> API, this becomes more important as time goes by.
> 
> Ideally, like we have a generic synchronous encryption API, we
> should have a generic hash API too, so that the user can use
> whatever hash that the underlying toolkit provides.

I rather like the fact that you can use htpasswd on one system and use 
the result on another system, regardless of the operating system. If 
we are willing to give that up, we may just make htpasswd use the more 
advanced schemes offered by the system's crypt() function.

Also, using what is available in the crypto libraries would limit us 
to PKCS5/PBKDF2, which is the only password hashing algorithm 
supported by openssl (AFAICS). Since PBKDF2 is based on sha256, 
though, it scales relatively well on GPUs. Of course, we could also 
implement other schemes on top of some cryptographhic hash or cipher 
provided by the crypto libraries. But I would rather avoid that 
because it's a lot of work to verify the result.

Mime
View raw message