MD5, password hashing and salt position

Question

Before i start, i know the MD5 is compromised (collision attack and speed of hashing) and shouldn't be used to hash passwords, but just for the sake of it, bear with me.

My questions are: How does the salt position when hashing with md5 affects the "quality" or the "strength" of the hash?

Say i have the the following piece of code, which hashes a users password using parts of his email address as salt:

<?php
    $email = '[email protected]';
    $password = 'RandomPassWithChars';

    $segments = explode('@', $email);
    list($saltPart1, $saltPart2, $saltPart3) = $segments;

    $hash = md5($saltPart1.$password.$saltPart3.$saltPart2);
?>

Is that code going to slow down a brute force / dictionary / rainbow table attack, than say:

<?php
    $password = 'RandomPass';
    $salt     = 'RandomSaltStoredInTheDatabase';
    $hash = md5($password, $salt);
?>

Is it worth trying to salt a password like in the first code or it yelds the same result as the second code? Are there any benefits from that? Does the first code delay cracking a list of passwords hashed that way than the second way of doing it?

Which leads me to a second question: Is it secure storing the salt in the database than obtaining a salt from a user id (say the email address) ? The way i see it, once an attacker has obtained a copy of the database which also cantains the salts it makes his life a little easyer trying to crack the hashes. But if the salts are not stored, the attacker would also need the algorithm that creates the salts. PLEASE CORRECT ME IF I'M WRONG.

I hope i made my self clear. Thanks for any answers in advance.

@Wooble that's true, but is there any difference between the two approaches of salting — Vlad Balmos
MD5 is NOT compromised when it comes to password hashing, there's no preimage on MD5. It IS, however, compromised when it comes to cryptography because of collision attacks. Having that in mind, I still think I wouldn't use it. — Adi
my bad, when i said compromised i was thinking speed of hasing and collisions — Vlad Balmos
possible duplicate of The necessity of hiding the salt for a hash — Thilo

Kendall Frey Kendall Frey · Accepted Answer · 2012-06-20T12:34:27

First question:

The position of the salt has no impact on the security of a particular hash. A good hash function has perfect entropy, in that for every input bit that changes, each output bit has a 50% chance of changing.

Any possible security benefit from a certain order would be entirely from the relative slowness of the algorithm used to concatenate the salt with the prospective password (e.g. if "password" . "salt" is slower than "salt" . "password", use the former). However, most programming languages don't have that kind of performance 'issue'.

Second question:

If the salt is stored explicitly in the database, the attacker will know the salt, and be able to launch a brute-force hashing attack. If the salt is unknown, a brute-force password attack can still be used (though this can easily be rendered ineffective by inserting delays between attempts). Also, the attacker may be able to reverse engineer the program and retrieve the hash field.

As for the security of the hash, if the user has the same email and password two different places, this negates one of the benefits of a random salt, in that the same hash will be visible both places.

Personally, I think the best method for hashing is to use:

"password" . "salt" . "internalconstantvalue"

This has the benefit of being simple, and no less secure than most other methods of security.

MD5, password hashing and salt position

3 Answers