Leszek,
On Thu, May 7, 2015 at 2:11 AM, Leszek Krupinski wrote:
> On Wed, May 6, 2015 at 4:00 PM, Nikita Popov wrote:
>
>> It should be further noted that there is no standardized crypt() format for
>> PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
>> PBKDF2 there would
Leszek Krupinski wrote on 07/05/2015 07:11:
On Wed, May 6, 2015 at 4:00 PM, Nikita Popov wrote:
It should be further noted that there is no standardized crypt() format for
PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
PBKDF2 there would be very problematic.
That's t
On Wed, May 6, 2015 at 4:00 PM, Nikita Popov wrote:
> It should be further noted that there is no standardized crypt() format for
> PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
> PBKDF2 there would be very problematic. We do already support it in the
> form of hash_pbk
On Wed, May 6, 2015 at 9:17 PM, Christoph Becker 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 stateme
Albert Casademont wrote:
> 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,
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
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
Nikita Popov wrote:
> On Tue, May 5, 2015 at 10:37 PM, Christoph Becker wrote:
>
>> In issue #64816[1] the OP suggests in the comment from [2015-05-05 04:34
>> UTC] that hash_pbkdf2() should be recommended for advanced users, and
>> that password_hash() should use PBKDF2 with at least 128,000 rou
On Tue, May 5, 2015 at 10:37 PM, Christoph Becker wrote:
> Hi everybody!
>
> In issue #64816[1] the OP suggests in the comment from [2015-05-05 04:34
> UTC] that hash_pbkdf2() should be recommended for advanced users, and
> that password_hash() should use PBKDF2 with at least 128,000 rounds.
>
P
While I agree that the statement "bcrypt is better than PBKDF2, thus only
bcrypt should be used" is difficult to defend, I think saying "bcrypt is a
homegrown solution, only PBKDF2 is a good way to do it" is also wrong and
OP is opinionated.
IMO - docs should describe alternatives, without stateme
Hi everybody!
In issue #64816[1] the OP suggests in the comment from [2015-05-05 04:34
UTC] that hash_pbkdf2() should be recommended for advanced users, and
that password_hash() should use PBKDF2 with at least 128,000 rounds.
The "Adding simple password hashing API" RFC[2] mentions in the "Future
11 matches
Mail list logo
