The iteration count is very different because in bcrypt it's not an
iteration count number at all, it's a "cost". And it's kinda exponential: a
hash with a cost of 11 is twice as hard to compute than that of a 10. At
our company we are using a cost of 11 right now, which means a hash is
computed in around 100ms in a Core i7

On Wed, May 6, 2015 at 9:17 PM, Christoph Becker <cmbecke...@gmx.de> wrote:

> Leszek Krupinski:
>
> > While I agree that the statement "bcrypt is better than PBKDF2, thus only
> > bcrypt should be used" is difficult to defend,
>
> Well at least the StackExchange thread[1] pointed out by Nikita supports
> the statement.
>
> > I think saying "bcrypt is a
> > homegrown solution, only PBKDF2 is a good way to do it" is also wrong and
> > OP is opinionated.
>
> ACK.
>
> > IMO - docs should describe alternatives, without statements "X is better
> > than Y", but we also should include PBKDF2 as an option for
> password_hash()
> > - PHP7 is (theoretically, apparently) closed for new features, but we
> > should target the next possible version. I'm not sure if we should opt
> for
> > changing the default.
>
> As Nikata has pointed out there is no standardized crypt-compatible
> format for PBKDF2, so it seems to be preferable not to add it to
> password_hash().
>
> > Regarding iteration count: (again, IMO) 1024 is a bit low, but 128000 as
> a
> > default for everyone might be a bit too much.
>
> As I understand it, the iteration count has to be very different for
> bcrypt and PBKDF2 (the latter requiring much more rounds).  Increasing
> the default cost factor of bcrypt from 10 to 11 or 12 seems to be
> reasonable, considering that 10 had be chosen nearly two years ago.
>
> [1]
> <
> http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage
> >
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to