But when I let my users register, I should do the same hash on the client side before sending using POST? So the hash will be sent as plaintext. So any attacker intercepting these packages can read the hash, create a custom request and use the hash to login under the user’s name?

Once again, thank you..

Just need to make sure.

lol, I jest..

Cool post.

Wish you write something about how to work with sessions in a way that a potential hacker could not log in even if he has got the DB and the sources both.

thanks too for wappalyzer !

$HashedPassword = $md5(md5($Password));

Increases the chance of collision dramatically?

So surely when running this -
for ( $i = 0; $i < 100000; $i ++ )
{
$hash = hash('sha256', $hash);
 }

you are increasing the chance of hash collision?

Im no expert and im unsure if MD5 and SHA256 work the same but I do know that it is a big NO NO to rehash a hash as it increases chances of collision.

For one thing, not all websites are a vacumn, thus whatever mechanism you may include the OPTION of validating at least initially to a different format. For example, many systems do store MD5 passwords, and it is a simple matter to export them when migrating. So for a special use case[migration of users], you would want to allow the user to sign in using their old password, and then immediately rehash and save it.

Additionally, you may be working on a web service for other users, in which case there should be an option to export data in a manner which allows people to use that data on their own server. Locking people into your system is rude and obnoxious, there should always be a migration option.

Lastly, there are indeed times when you will need to allow a site owner to log on as someone else. Customer service is key. In those cases, explaining how much more secure the password system is is useless, you must give them a way to log on. Either store the password in some manner that they can look it up, or provide functionality to allow an admin to “impersonate” a user.

Doesn't work as written. Need to concatenate the user's input password with the salt again after getting it from the login form . . .

… . $r = mysql_fetch_assoc(mysql_query($sql));

// The first 64 characters of the hash is the salt
$salt = substr($r['hash'], 0, 64);

$hash = $salt . $password; <—————— (TYPO FIXED) INSERT THIS LINE HERE (IN 2ND CODE SECTION)

// Hash the password as we did before
for ( $i = 0; $i < 100000; $i ++ )
{
$hash = hash('sha256', $hash);
} … . // ETCETERA

… . $r = mysql_fetch_assoc(mysql_query($sql));

// The first 64 characters of the hash is the salt
$salt = substr($r['hash'], 0, 64);

$hash = $hash . $password; <—————— INSERT THIS LINE HERE (IN 2ND CODE SECTION)

// Hash the password as we did before
for ( $i = 0; $i < 100000; $i ++ )
{
$hash = hash('sha256', $hash);
} … . // ETCETERA

Then :
- you wouldn't increase the chance of collisions
- you wouldn't increase the server load

Hashing multiple times may increase the chance of collisions slightly but I don't think it matters to much in this case. You'd still have to perform the hash a 100,000 times which slows brute forcing down significantly. If computers get faster you can just hash all the passwords some more.

If I have access to the database, I could just look at the first 64 characters and create a new rainbow table. The only real difference is that it will take more time to “decode” the password of ALL users, but when you're looking at a single password, this method doesn't seem more secure.

Also, I'm not a security expert , but is it really better to hash something multiple times?

However you presume usernames are fixed and TheName is another user as thename > strtolower($username)