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