Originally Posted by echoSwe Yes, but a salt is different for every row in the database, not hard-coded like you wrote... You should create password criteria at sign-up. However, whether they use 'password' as their password or not is really not interesting in this discussion, but rather how to store their password in a way that doesn't open too wide avenues of attack. You should create password criteria at sign-up...

It depends. Neither of us are wrong You can have a static salt, which is hard coded into the PHP script. This is more practical in PHP, but you can also set a random salt and prefix the password with it before encrypting with the chosen algorithm. The salt would then be stored in the database though, which means if an attacker wanted a specific password, then could make a program to brute-force or dictionary attack the password still. Each method has advantages and disadvantages.

Set String:
+ Salt is only available from the script; attackers would need file access as well as database access;
+ The salt can be changed if it is found to be discovered;
- If the salt is discovered, tables can be generated to calculate all the passwords.
- A user could sign up with a password and grab their hash from any cookies; from here they could brute-force the salt and generate tables to crack all the other passwords.

Random String:
+ The salt is different for each password, and so tables can not be generated at all;
+ The salt is not stored anywhere, and providing a proper random function is used (not a calculation), then the salts can not be re-calculated for each password;
- The salt for each password need to be stored somewhere in correspondence with the hash; this leaves space for an attacker to find the salt for a specific password.

Nice function JochenVandeVelde lol... it'd take a decent computer about a year to crack one of those passwords if it's length was 0 > l >= 6 characters I reckon!!