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
>
