Dave Tolls wrote:Hashed with salt.
Adam Scheller wrote:Hashing is the right way to do this. It's one-way algorithm that does not allow to "decrypt" a password, because password information is not stored. A hash is a result of mathematical transformations performed on input data (in this case, on a password). One set of data has only one hash, thus only one password has only one hash representation.
A hash cannot be transformed back to the password. Thus to verify user password you have to hash user input and compare it with the hash in the database. If a match is made, then the correct password is provided (as one password has only one hash).
One last tip: Many old articles and tutorials on Internet commonly use MD5 for hashing passwords. This hashing function is already cracked and is considered to be useless. Under any circumstances, do not use MD5!
Rob Spoor wrote:
Adam Scheller wrote:(...) One set of data has only one hash, thus only one password has only one hash representation. (...)
Not necessarily true. For instance, in PHP, the password_hash function generates a new value every time. That's why you can't simply hash the password to check and compare that, but you have to use password_verify to validate the value instead. As far as I know, the same is true for BCrypt. In other words, one password has many, many hashes. This provides extra security, as crackers can't just try to pre-generate a lot of hashes and try these.
Returns the hashed password, or FALSE on failure.
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.
Rob Spoor wrote:In other words, one password has many, many hashes. This provides extra security, as crackers can't just try to pre-generate a lot of hashes and try these.
Winston Liek wrote:But where should I store the salt value? Isn't it the salt becomes useless if I will store it in the same database? If the hacker gets access to the database containing hashed passwords, for sure he can access the whole tables in the database and will be easily track the salt columns.
Winston Liek wrote:And also, if I use one salt per web app (not per password), is it possible for hackers to access my deployed web app in the server?
Dave Tolls wrote:I've got one.
Sites that have a max size for your password.
Bit of a giveaway that they're rather unlikely to be hashing it in any way.