On Wed, Jun 20, 2012 at 1:25 PM, Nick Edwards <[email protected]> wrote:
> Hello,
>
> 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.
>
> 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!
>
> Apache currently only offers SHA1 which is about as secure (can be
> read as , as hopeless as) MD5.
>
> Can the project devs/team leaders indicate if there are future plans
> to mnprove the basic auth security methods up to SHA512?

This thread is all over the place!

So, a summary...

* SHA-1 is not as broken as MD5 - no way to generate collisions has
been found that is practical.

* MD5 is still pre-image resistant even though it is possible to
generate collisions. This means that repeated applications of MD5 are
also pre-image resistant.

* The threat against md5crypt is the same as it has always been:
rainbow tables. The current attacks have not changed this.

* htpasswd uses an 8 byte salt with 6 bits per byte. So, a rainbow
table will have 2^48 entries per password. Assuming you can somehow
manage 1 byte per entry, that's still nearly 300 TB per password.

So, I'd say there's no need for panic, but there's also no reason that
I can see to not move to a more modern scheme.

Then the question is: what scheme? Here are some design criteria I
think would be useful.

1. Use something from the SHA-2 family - SHA-512 would seem fine to me.

2. Use a very large salt - disk space is not at a premium for password stores!

3. Use quite a lot of rounds,.

4. Use something that is hard to optimise in hardware (ideally).

Reply via email to