/    Sign up×
Community /Pin to ProfileBookmark

passowrd_hash() Issue

Hi,

Seem to be having problem with the password_hash() as it keeps changing the hash value of the same password. Why ?
When each time I refresh the page, the $password_hashed value changes! Why ? The $password is still the same who’s value is: ‘123’.
And password_verify($password,$db_password) always echoes ‘1’ (TRUE). How so, since the $hashed_password value changes each time ? Odd!

Try this code in your browser and see for yourself.
Refresh the page on each occassion and see what you get echoed!

echo ‘password: ‘ .$password = ‘123’; echo ‘<br>’;
echo ‘password hashed: ‘ .$password_hashed = password_hash($password,PASSWORD_DEFAULT); echo ‘<br>’;
//$db_password or database password is now the hash: $2y$10$cie0yEEiLdJkK3IDj8ABXO/vTMvR3F3twO2SVY1VC6D3zP1Fp/xPW

echo ‘db password: ‘ .$db_password = ‘$2y$10$cie0yEEiLdJkK3IDj8ABXO/vTMvR3F3twO2SVY1VC6D3zP1Fp/xPW’; echo ‘<br>’;
echo password_verify($password,$db_password); //echoes ‘1’ (true).

I understand that the hash value changes each time due to the SALT changing each time on page refresh but how will the password_verify() know which SALT to use on each occassion to decrypt the hash ?

to post a comment
PHP

8 Comments(s)

Copy linkTweet thisAlerts:
@ginerjmDec 30.2022 — Not at all familiar with the use of these functions but from reading very carefully I believe there is nothing wrong here. Each execution of the hash function generates a string that contains the values used to generate it. The verify uses that info to properly evaulate the hashed password and the result comes out as expected, ie, True
Copy linkTweet thisAlerts:
@tracknutDec 30.2022 — @ginerjm#1649538 yes correct. From the manual:

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.
[/quote]

So the salt and the algorithm used to do the hash are included in the returned value (i.e. it doesn't just return the hash itself) so that the verify routine can figure out how to has the subsequent test password.
Copy linkTweet thisAlerts:
@ginerjmDec 30.2022 — Yes - the manual makes sense in what it says. Too bad our OP just never bothers to look at it before posting his myriad of questions here.....
Copy linkTweet thisAlerts:
@NogDogDec 30.2022 — The only time you need to hash it is when setting/changing the password and then saving to the DB. This means that to check it at login, you have to fetch the hash from the DB, then check it in the PHP code using password_verify(). That means you cannot do what is typically done with more traditional hash techniques, where you can hash the input login password and then use that in the DB query to verify the login attempt. (The benefit though is that if someone hacks your PHP code, they cannot find your salt mechanism or such to help them hack your DB passwords.)
Copy linkTweet thisAlerts:
@ginerjmDec 30.2022 — I think we are all in agreement on what's what here. Just awaiting the OP's recognition of these responses and his acknowledge that he doesn't have a problem with the code sample he provided.
Copy linkTweet thisAlerts:
@novice2022authorJan 08.2023 — @ginerjm#1649545

I did check the manual before opening this thread!

Question was, if php by default uses it's own algo to create the salt and salt changes each time then how does php know which salt to use for the password when logging in time ?

The manual did not answer that. That's why I opened the thread. NogDog, I think answered my question briefly but it was too brief for me to understand.
Copy linkTweet thisAlerts:
@novice2022authorJan 08.2023 — @NogDog

I understand what you are saying. That, if someone hacks into my db then they won't find the salt since php uses it's own salt by default and salts change each time as no good using the same salt because if there is only one salt then it would be easy to figure that out in 10 secs. And no need for me to create any salts to insert into db as php uses the built-in salts to save our salts from falling into hackers hands.

But my original question was, if php by default uses it's own algo to create the salt (where salt changes each time) then how does php know which salt to use (to dehash the password) during logging in time ?

As far as I am concerned, php interpreter might have 10k salts built-in. During registration, it might use the 1st salt and hash the password. But during logging in time, it might check the hashed password against, say salt number 999 and not against number 1. In that case, since it's using a different salt this time (during logging in) there will be no password matches. That was myquestion.

Or maybe, php interpreter or password_verify() checks against all available salts that php interpreter uses by default, in our case check against all the 10k salts ? This is likely to be the case.

I think you now understand my question and understand why I opened this thread. Unfortunately, Ginerjm neither understood the issue nor my question. ANd came jumping at me with an accusation I did not bother to check the manual. The manual does not ansqer my question. My question is very basic. Manual should have answered it so programmers do not get confused to how the password_verify() guesses & uses the right SALT.

**EDIT:

I now suspect, the salt number is added to the hash during hashing time.

And when it is time to dehash the password, the password_verify() checks the hashed password and finds the part of the code that signals which salt number is being used and then uses that built-in salt during password dehashing. That way, no need for php interpreter to check the hashed password against all available SALTS that are built-in to the php interpreter. Do you think I am correct ?**
Copy linkTweet thisAlerts:
@ginerjmJan 08.2023 — Once again I find your ability to read and understand being challenged. Here is what the Manual does in fact state:

Return Values

Returns the hashed password.

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.
×

Success!

Help @novice2022 spread the word by sharing this article on Twitter...

Tweet This
Sign in
Forgot password?
Sign in with TwitchSign in with GithubCreate Account
about: ({
version: 0.1.9 BETA 5.23,
whats_new: community page,
up_next: more Davinci•003 tasks,
coming_soon: events calendar,
social: @webDeveloperHQ
});

legal: ({
terms: of use,
privacy: policy
});
changelog: (
version: 0.1.9,
notes: added community page

version: 0.1.8,
notes: added Davinci•003

version: 0.1.7,
notes: upvote answers to bounties

version: 0.1.6,
notes: article editor refresh
)...
recent_tips: (
tipper: @AriseFacilitySolutions09,
tipped: article
amount: 1000 SATS,

tipper: @Yussuf4331,
tipped: article
amount: 1000 SATS,

tipper: @darkwebsites540,
tipped: article
amount: 10 SATS,
)...