If you develop an application that manages passwords, it is important to do so on pain of risking piracy of your system and compromise your data users.
There is good practice to store a password.
The right way to store
Store the login and hash (login + password + salt)
Pseudo-code: passwordHash = MD5MD5( login + "zo5pro$1pvkhj6*cz4a8ùtvb#ui4oeuio" + password)
Store and passwordHash login. Do not store password.
We should never store the password in clear text.
- Risk: If someone breaks into your database of passwords, it can retrieve and use them directly.
- Protection: The hash used to calculate a fingerprint of the password. As the algorithm is not reversible, it can not immediately find the password from the hash.
- This is why we use a cryptographic hash. Typically MD5, SHA-1 or other (SHA-256, SHA-512 ...)
- Never use a CRC or CRC32.
Why using salt?
The rainbow-tables are large tables containing hash (MD5, and others) precomputed.
This allows you to quickly find the password that gave a specific hash.
: If you just use MD5 (password), the rainbow-tables allows to recover the password to MD5 in minutes, even seconds.
: Using a salt, this makes the rainbow-tables completely unnecessary.
The salt is an arbitrary value, the length of your choice. Set it as a constant in your application.
Why add the login?
If you just store MD5 (salt + password) or MD5 (password), this means that two users with the same password will have the same hash.
- Risk: You can easily identify the users with the same password. If a user is compromised, it allows immediate access to other users (who may have greater rights).
- Protection: By adding the login before hasher, the MD5 result will be different for each user, even if they have the same password.
When you receive login and password, you simply repeat the same calculation:
Thanks to sebsauvage for this tip.
- Look in your base, for the hash for this login
- Compare the hash value (login + salt + password)
- If the two hashes are identical, the password entered is correct.