On Wed, 20 Jun 2012, Nick Edwards wrote:
I posted this to users list last week but no-one bit, so I'm trying here.
With md5crypt no longer recommended for use by its author, will Apache
soon support sha256/sha512 in basic authentication via MySQL.
Note that it does not really matter that much which hash algorithm is
used. The number of rounds is more important. APR-MD5 ("$apr1$") does 1000
times recursive md5 (which is 1000 times more secure in terms of brute
forcing than plain md5). We should switch to something that needs more
processing time so that it is more difficult to brute force.
I understand the apr version is different to plain md5crypt, but it is
based on the same thing from what I can tell, so its pointless
upgrading our database passwords to use sha512 if Apache's still the
weak link.
All admin scripts run in perl, and we are currently doing this with
apache_md5_crypt($password); using Crypt::PasswdMD5
For Mail and FTP, we are _now_ successfully using crypt($password,
'$6$' . $16charsalt) for sha512, be nice if Apache basic auth would
too!
APR passes everything it doesn't know to the system's crypt() function. So
chances are good that using $6$... already works for you. However, there
is currently no way to create such hashes with htpasswd.
Apache currently only offers SHA1 which is about as secure (can be
read as , as hopeless as) MD5.
The sha1 algorithm in htpasswd is only for compatibility with some other
product. It is extremely weak (no salt, one round only). The APR-MD5
algorithm is *much* more secure.
Can the project devs/team leaders indicate if there are future plans
to mnprove the basic auth security methods up to SHA512?
I would be for importing some state of the art scheme from some BSD. Good
schemes allow to change the number of rounds without loosing backward
compatibility. I guess bcrypt is a candidate. This new algorithm should
then be the new default.
In addition, we may want to provide some md5 algorithm with more rounds.
Then it should be possible to convert old $apr1$ hashes into stronger
hashes without having to know the original password. Of course, people
would need to take care that the old 1000-round hashes are securely
deleted everywhere.
Cheers,
Stefan
