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; > > 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. 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 salt. 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. Cheers, Stefan
