This question already has an answer here:
Trying to understand password_verify PHP
(1 answer)
Closed 5 years ago.
I use PHP's password_hash and bcrypt algorithm to hash my passwords. They are in MySQL database.
password_hash($password, PASSWORD_BCRYPT);
As obvious every hash generated by this function is different. But is it really necessary, to identify user by email/login or something to grab his hash from database and then verify it with PHP's password_verify()?
Is it really necessary to make this query and then check?
I mean, is it possible to check hash before, and after only do query to check if it matches this one in MySQL?
Or something else maybe? I remember years ago I used something like checking inside query, like
WHERE login = $login and pass = PASSWORD($password)
Especially I mean this PASSWORD($password)?
Is there other option than fetch user's hash from Database and then verify this hash with password_verify()?
Yes, it's necessary. You need the unique salt generated during hashing, encoded as part of the hash, to do the comparison. That's also exactly why this algorithm is so strong for password storage.
Related
This question already has answers here:
How does password salt help against a rainbow table attack?
(10 answers)
How can bcrypt have built-in salts?
(5 answers)
Password hashing, salt and storage of hashed values
(4 answers)
Closed 3 months ago.
I am wondering about how password_verify() verifies the hash, I have reviewed the documentation and many answers in StackOverflow, but I didn't get the idea
because, as I understood, this function will compare the hash with entered password after hashing it again, and use the same salt and cost and algorithm,
but the question here: if anyone can separate the salt from the hashed password, then anybody also can try to use rehash and try to match, and the salt will be useless here. Am I right, or what?
The salt have to be generated randomly each time the fonction is used (and it's what this function does, and not accept custom salt anymore).
For example:
<?php
$password = "nothing";
echo password_hash($password, PASSWORD_DEFAULT);
echo PHP_EOL;
echo password_hash($password, PASSWORD_DEFAULT);
Give the response :
$2y$10$mdJRjsoc1vR11SKa2JDyS.qSlxja/a0SUPuXC1NKsRLkzmayKwjku
$2y$10$H2th6dRY/i.xZzXSGxDZ1uaiwZx6s0.FM0NXcBcBQ0E2aNEHCJ57m
It's the same password with differents results.
The hashed password is stored in a database or a file. In this case, an admin system (or someone who's hacked the database) can't say if the same password is used by differents users. Another point, rainbow tables can't be used with hashed password with salt. Only brut force can be done.
Using the same salt for all is not more secure than using simple hash algorytm.
This question already has answers here:
password_hash returns different value every time
(1 answer)
Using PHP 5.5's password_hash and password_verify function
(4 answers)
Closed 5 years ago.
I have a technical question regarding password_hash() & password_verify().
If I run a sample password through password_hash() many times, I get a different result each time. I guess that’s a Good Thing.
The question is how does password_verify() actually verify the candidate password if the actual hash keeps changing?
I ask this question here because it is PHP related.
For those who think this question is a duplicate:
This question is not a duplicated of the linked questions. I am aware that the value changes, and that password_verify_ works with that.
It is a question of how that happens.
As noted on the manual page for the password_hash() function,
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.
When the same inputs - algorithm, cost, salt and password - are fed into the password calculation, the same output will be generated. Thus, the password_verify() takes the algorithm, cost and salt from the original calculation, generates a new hash using the password being tested, and compares the previous result with the newly generated one. If they match, the verification succeeds, otherwise it's an error.
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 7 years ago.
From my understanding so far (at least I think) the password_hash() function generates a hash based on the algorithm in use, cost and the salt. While the password_verify uses the information provided from e.g. password_hash($pass, PASSWORD_BCRYPT, array('cost'=>10)) to check if the retuned value is true or false as it contains all the information necessary for verifying.
I previously used
$SQL_Query = "SELECT * FROM DB_Table WHERE userName = '".$username."'" AND password = $ID;
which would work as they were stored in plain text and could return true whereas logically it won't work this time around.
I have came across similar questions where they use static passwords in explanations such as
<?php
$to_verify = '$2y$07$BCryptRequires22Chrcte/VlQH0piJtjXl.0t1XkA8pw9dMXTpOq';
if (password_verify('rasmuslerdorf', $to_verify))
{
echo 'Password is valid!';
} else
{
echo 'Wrong password.';
}
The concept I am having trouble understanding is how one would check the password input against the hashed value if it is stored in a database rather than the being known by the page at that point in time? I recently got help regarding storing the values which was a silly error on my part but I guess this isn't clicking with me as well as I hoped for the moment.
Look at the examples for password_hash() and password_verify() together.
The hash-string that's produced by password_hash is self-describing: it incorporates an indication of both the algorithm and the random-salt that was used. password_verify knows about all this. It knows how to "do the right thing" for passwords both recent and vintage.
Therefore, simply query the database to get the (hashed ...) password for this user. Then, use password_verify() to see if this hash-value matches this password-value.
You can't query for the user-name AND password at the same time. Query only for the user-name, get the hashed value, and use password_verify() to check it.
the hash is generated randomly each time
No, the hash is always the same for a given input, salt value and iterations through which the hash algorithm is run (which is controlled by the cost parameter).
The concept I am having trouble understanding is how one would check the password input against the hashed value if it is stored in a database rather than the being known by the page at that point in time?
You would check the password input at login time, using the password provided by the user, and the salt and potentially number of times to apply the hash algorithm associated with that user. Once the password check is successful, use a session or other mechanism to keep the user logged in.
This question already has answers here:
PHP Crypt() Compare two crypted strings
(5 answers)
Closed 8 years ago.
I generated an encrypted string with using blowfish encryption function (crypt()) in php and stored it in database. How can I check correctness of submitted password then?
For eg. during registration, I defined my pass as "1234" and then generated a random key and then my blowfish encrypted password something like "$2a$08$xPIviMLmVMHLQdzb$$$$$.OdQVKDPJeK4KIcdqnngIgv41lILjKR." So, when user comes back, how can I check correctness of his/her password? Is there any comparing function of two encrypted string from the same base password or another efficient way? Thanks in advance.
Simply pass the user input from the form into the crypt function, with the hash in the database.
For example:
<?php
if (crypt($passwordFromPost, $hashedPasswordInDb) == $hashedPasswordInDb)
{
// User has been authenticated
}
Passwords are usually not encrypted but hashed. It is not possible to regenerate the original password from a hash.
To find out more about password hashing in PHP the manual is a good starting point PHP manual
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 8 years ago.
Is there an advantage as to where password hash and salt occurs, in PHP vs in a database? It seems having the process occur inside of a database would be the optimal solution; since the web server and the database would only have to exchange the password and not the salt.
It's okay to store the salt in the database. It's an advantage to do so, because you want to use a different random salt per user.
I recommend doing the hashing in the application.
The reason is that if you do the hashing in an SQL expression, and you use query logging on the database server, you might be storing plaintext samples of the user passwords in the query log.
If you're using something better than a simple hash + salt, like PBKDF2, you're going to have to involve PHP at this point AFAIK. So in terms of best location, for me, the best location is in the code because that's where you can do the "best" method of password hashing.