Increasing the Calculation Cost of Hashing

Question

Is this a secure way to increase the calculation cost of md5 or sha1?

public static byte[] increaseHashComplexityMd5(byte[] hash, int loops)
{
    for(int loop = 1; loop <= loops; loop++)
    {
        hash = md5(encryptAes(hash, reverseBits(hash)));
    }
    return hash;
}

public static byte[] increaseHashComplexitySha1(byte[] hash, int loops)
{
    for(int loop = 1; loop <= loops; loop++)
    {
        hash = sha1(encryptAes(hash, reverseBits(hash)));
    }
    return hash;
}

reverseBits reverses every bit of every byte, so 12345678 90111213 becomes 31211109 87654321.
encryptAes encrypts the hash by the hash-with-reversed-bits, will result in a 16 x blocks result.
md5/sha1 hashes the given bytes.

My goal is to make it harder to bruteforce hashes. On both platforms (C++ and Java), I already have the hash, aes and reverseBits functions, so something like this would be ideal. Will this do it, or is this insecure?

score 14 · Accepted Answer · edited Mar 17 '17 at 13:21

No, it is not a "secure" way. It is a home-made construction that merely throws together hash functions and symmetric encryption under the hope that the resulting mixture will be strong in some way.

Truth is, in the specific case of password hashing (as opposed to simple hashing, which is a very different activity), such slapping of algorithms together tends to work. But you still managed to get several things wrong. Namely:

Your system is not salted, so when an attacker must crack several passwords, he can optimize things with parallelism and precomputed tables.
The point of using many iteration is to make each password try expensive, but the attacker has the resource to use dedicated hardware that will be more efficient than yours. In this case, both MD5 and AES can be considerably sped up on off-the-shelf GPU (for AES, using bitslicing techniques, as in the Käsper-Schwabe implementation), thus allowing the attacker to hash more passwords per dollar than you.

Read this answer for more information on what is needed for good password hashing. The short summary is: use bcrypt, with one of the already available libraries. It will be stronger than your creations, and easier to implement since it is already done.

I don't really see the point of your remark about the attacker being able to hash more passwords per dollar than you... who cares? The users don't bruteforce their password, so the same number of hashes achieve very different rates at correct login. Obviously if a big organization wants to brute force your db they probably *will* have better hardware and stuff so you must assume an attacker will be able to do more hashes per dollar than you, and your scheme must still hold secure against this threat. — Bakuriu, Mar 11 '16 at 14:59
@Bakuriu Specialized hardware is the name of the password-cracking game right now. An attacker might not have the hardware sitting in front of them, but usually buys time on a password cracking farm that makes money off of attackers buying time to brute-force passwords with their hardware. Might only cost a few bucks to the attacker per password if it's hashed with MD5, which considering what might be the stakes, that might very well be worth it. — sethmlarson, Mar 11 '16 at 19:31

Increasing the Calculation Cost of Hashing

1 Answers1