On that note I have only one request - please point me to the good article that describes how this thing works (I would prefer one that at least tries to explain in simple words) because at the moment i do not understand how salt stored in the hash itself makes hash more secure than an unsalted one.
Thank you :-) 27.06.2012 14:16 пользователь "Anthony Ferrara" <ircmax...@gmail.com> написал: > Arvids, > > On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks > <arvids.godj...@gmail.com> wrote: > > Hello. > > > > I personally think that using PASSWORD_DEFAULT for algorythm by default > is a > > bad idea. This should be defined by user in the code. Even worse if it is > > defined by .ini setting - deploy to a remote server and realize that > there > > is a different .ini default that messes up everything. Lessons learned in > > the past are forgetten fast? > > It wouldn't mess up anything. All it would do is change the algorithm > used by the library when creating new passwords. Existing ones will > still validate. The new ones will validate on the old server as long > as that algorithm is supported (could be an issue in a mixed > environment where there are servers using an older version without > support for the new method in crypt())... > > > And the thing I don't get is how do I verify a salted password? I have > read > > throught the RFC and what I know about the salts makes me wonder - how da > > hell I will verify my salted hash if I can't pass the salt to > > password_verify? > > Ah, I think I see the disconnect. crypt() returns the full salt > information along with everything necessary to hash it (all settings). > So the generated hash includes the salt, the method, and the cost > parameter. For example: > > var_dump(crypt("rasmuslerdorf", "$2a$07$usesomesillystringfor")); > > string(60) "$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi" > > So just storing the hash is enough... > > > If there is some trick behind, it should be explained in the RFC (and in > the > > docs later, because otherwise it makes people WTF?! who are not into > > cryptography). > > That's completely fair. I'll add a section to the RFC about that... > > Thanks, > > Anthony >