httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: Choosing a stronger password hash algorithm
Date Fri, 29 Jun 2012 09:23:21 GMT
On Tuesday 26 June 2012, William A. Rowe Jr. wrote:
> 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.

Passing some salt string like "$6$" to crypt() is just a different way 
to call a library. And on FIPS compliant systems, the system's 
password hashes are likely also FIPS compliant. But this approach 
would not work for platforms like Windows that don't have crypt().

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

There is some confusion here between crypt() the function and crypt 
the algorithm (i.e. DES-crypt). On Linux and BSDs, crypt() supports 
more secure algorithms than DES-crypt.

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

The first paper doesn't mention password hashing at all. The second 
one mentions stretching only to make creation of rainbow tables more 
difficult. But increasing computation time by stretching is also 
important for simple brute force attacks without rainbow tables. And 
the reason why the md5crypt author has recently declared his algorithm 
insecure is the too low computation time and nothing else.

The salting definitely can be improved. htpasswd only uses 2^32 
different values on a given libc. htdbm only uses the timestamp as 

Apart from that I think that we should do both things: Add a good non-
FIPS compliant algorithm that is built into APR and a FIPS compliant 
variant (whatever that is). The former is straightforward but the 
latter isn't. For example with PBKDF2, you have to define an output 
format because none is defined yet. Also, one must choose a suitable 
size of the resulting key. And I don't really know if PBKDF2 is 
actually FIPS compliant. Then there is the question of the API: Would 
we add a replacement function for apr_password_validate() that also 
takes an apr_crypto_driver_t argument? Or would we make some 
apr_password_set_driver() function that sets the driver to be used by 
apr_password_validate()? Do we also need a way to disable non-FIPS 
compliant algorithms?

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. I 
would be willing to help anyone who wants to add a FIPS compliant 
scheme, but I am not going to do the necessary research myself. And I 
don't think we should delay the release of a new apr-util with bcrypt 
support for a FIPS compliant scheme that may or may not be added in 
the future.


View raw message