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.
