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 Mon, 25 Jun 2012 22:13:41 GMT
On 6/24/2012 3:34 AM, Stefan Fritsch wrote:
> On Sunday 24 June 2012, Graham Leggett wrote:
>>
>> 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.

You misunderstand.  The algorithms need to exist in the apr crypt
implementation.

We might choose to provide 'fallback' implementations if the are absent.

This gets you to things like FIPS-140-2 implementations when APR is
correctly configured and built, without the hassle of validating our
own implementation.  We aren't put in a position of implementing the
assembly language optimized flavor, because the library vendor has
already done this.

Nobody is talking about crypt(), although generic implementations of
crypt() are offered by openssl and likely from gnutls etc.

> 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.

Take a quick glance through these two drafts;

http://csrc.nist.gov/publications/drafts/800-107/Draft_Revised_SP800-107.pdf
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf

I think we may be dwelling too much on computation time.  The larger issue
is better seeding.  An illicitly obtained password file of hashed p/w's
will always be a risk to the accounts, irrespective of computation time.
What is critical is the seeding such that duplicate passwords are not
obvious, and that passwords recycled on other services don't demonstrate
the same hash (ergo, collision) value.


Mime
View raw message