We are working on a simple login/registration form. Our login script checks to see if the username and password exist in the same row of the database. If it does exist, we bring the user to a welcome page.

However, our problem lies when we check to see if the password exists in the database because we have applied the password_hash() function to the user submitted password. This encryption method is one-way and not reversible (to my knowledge). Here is the code for the login script:

//will correspond with 'loginLogin.html page
$user = $_POST['username'];
$password = $_POST['password'];

$stmt2 = $conn->stmt_init();
$stmt2 = $conn->prepare("SELECT * FROM login WHERE alogin = ? AND apassword = ?"); 
$stmt2->bind_param("ss", $user, $password);
$numberofrows = $stmt2->num_rows; //this is an integer!!
$stmt2 -> close();

if($numberofrows > 0) //if username and password combination exists in a row 
    echo 'login successful!';
    echo 'Incorrect username and/or password, dumbass!';

I was thinking perhaps we could encrypt the password AGAIN inside this script and see if the two hashes match, however the encryption changes each time regardless of whether the same exact password was hashed!

As of right now the username/password combination will never exist and will always hit the last "else" statement. Any ideas how to check for the correct username/password combination?


2 Answers 2


Attempt to fetch the user record based on the username (but use LIKE instead of = so that case doesn't matter. Usernames should not be case sensitive.

If you managed to fetch a user record (then the user exists) and you can compare the passwords to validate the login.

About password security

Store the passwords using a function like password_hash() so that they're far more secure than being stored plain text (a huge no-no). This will generate unique salt each time so yes the hash will be different each time. Don't worry about that.

To validate the password the user is logging in with against the stored password, use password_verify() and pass it the password they posted and the stored hash from the database. The function will take care of the salt and comparison. This is the function that I think you might've missed when reading about password hashing.


After successful login you should check to see if the password needs re-hashed (over time the "cost" of the algorithms are updated). Simply pass the stored hash to password_needs_rehash() to see if you should re-hash and re-save the password.

  • Thank you!! Did not know about password_verrify() Commented Aug 19, 2015 at 0:55

Typically I'd just search the table for the record that contains the matching username. If that record doesn't exist the user doesn't exist so there is no need to go any further.

If the record does exist that record would have the password hash on it for that user. Take the password given by the user, hash it in the same way, compare to the hash in your record.

  • Yes, I have thought of this but each time the password is hashed it produces a different encryption! For example if I hashed the same password twice: password_hash("password1234", PASSWORD_DEFAULT); password_hash("password1234", PASSWORD_DEFAULT); This will produce two different encryptions! Commented Aug 18, 2015 at 22:35
  • A hash function produces the same output given the same input. Otherwise it's not a very good hash function. Why would you ever hash the password twice? If you've saved lots of records with password hashed in different ways and don't know how they were hashed that's a "bad thing" Commented Aug 18, 2015 at 22:36
  • 2
    Yeah, it comes out as a new encryption code everytime because password_hash() adds a new "salt" to every password Commented Aug 18, 2015 at 22:40
  • 1
    So, find the record by matching on user name. That gives you the salt. Then hash the provided password using that salt, and compare to the hashed password in the table. Commented Aug 18, 2015 at 22:44
  • 2
    Just a follow up to our discussion - as I couldn't believe there was a function in php that randomly added salt that you couldn't then get access to..... It appears the salt is included in the returned value from password_hash (so it returns hash + extra info), but then you need to use a separate function password_verify with any other password attempt to compare it to this stored value. Commented Aug 18, 2015 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.