Hello all,
Since there wasn't that much traffic on the draft version of the RFC,
I've moved it into Proposed.
https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
Thanks,
Anthony
https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
That's very nice, indeed.
One thing I'm wondering about is whether the last parameter could be
changed from:
raw_output = false
To something like:
output = "hex" (also allowing output = "raw", output = "base64")
Just thinking that most of the time I'd prefer storing the hashed
passwords as base64-encoded strings just because it's more compact,
but this isn't a big deal, just a thought.
Really nice work!
Adam
https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
That's very nice, indeed.
One thing I'm wondering about is whether the last parameter could be
changed from:
raw_output = falseTo something like:
output = "hex" (also allowing output = "raw", output = "base64")
That wouldn't be consistent with the rest of the hash_ family though :)
Just thinking that most of the time I'd prefer storing the hashed
passwords as base64-encoded strings just because it's more compact,
but this isn't a big deal, just a thought.Really nice work!
Adam
On Tue, Jun 19, 2012 at 6:23 AM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:
One thing I'm wondering about is whether the last parameter could be
changed from:
raw_output = falseTo something like:
output = "hex" (also allowing output = "raw", output = "base64")That wouldn't be consistent with the rest of the hash_ family though :)
I agree that keeping the API consistent throughout the hashing family
should be a priority. That said, this function signature is quite
different from the other hash functions. Additionally, the practical
value of this function relates specifically to password storage, and
giving the developer easy, efficient access to more compact storage
strings would likely prove helpful.
Adam
hi Anthony!
Hello all,
Since there wasn't that much traffic on the draft version of the RFC,
I've moved it into Proposed.https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
Very nice work! Thanks :)
I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).
About adding this to 5.4, I do not think it should be done. This is
not a small change and it may require more testing, both for the
implementations or the API (while it is fairly simple as of now :).
php-next is next year anyway.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
Very nice work! Thanks :)
Thanks!
I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).
When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with PBKDF2? Or
other iterated stretching algorithms similar to PBKDF2?
About adding this to 5.4, I do not think it should be done. This is
not a small change and it may require more testing, both for the
implementations or the API (while it is fairly simple as of now :).
php-next is next year anyway.
I'm not arguing that. When I proposed the draft earlier I had
indicated that it was for trunk, and others said it could go into 5.4.
That's why I put that section in the RFC. Personally, I'm in the
middle. I can see some advantage to adding it to 5.4, but I can also
see some disadvantages. So I leave that decision to others (such as
yourself).
Thanks,
Anthony
hi Anthony!
I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with PBKDF2? Or
other iterated stretching algorithms similar to PBKDF2?
The algos recommended to use with PBKDF2.
About adding this to 5.4, I do not think it should be done. This is
not a small change and it may require more testing, both for the
implementations or the API (while it is fairly simple as of now :).
php-next is next year anyway.I can see some advantage to adding it to 5.4, but I can also
see some disadvantages. So I leave that decision to others (such as
yourself).
There are always advantages to do it. But they do not help the big
picture. However, besides what I said earlier, fast releases of
features, 100% BC releases will ease the move to newer versions,
faster than the horrible situation we have now. If we keep merging
features, nobody will migrate, ever or until they have no other
choices.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
hi Anthony!
On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with PBKDF2? Or
other iterated stretching algorithms similar to PBKDF2?The algos recommended to use with PBKDF2.
I will update the RFC tonight...
About adding this to 5.4, I do not think it should be done. This is
not a small change and it may require more testing, both for the
implementations or the API (while it is fairly simple as of now :).
php-next is next year anyway.I can see some advantage to adding it to 5.4, but I can also
see some disadvantages. So I leave that decision to others (such as
yourself).There are always advantages to do it. But they do not help the big
picture. However, besides what I said earlier, fast releases of
features, 100% BC releases will ease the move to newer versions,
faster than the horrible situation we have now. If we keep merging
features, nobody will migrate, ever or until they have no other
choices.
You have me convinced...
Anthony
Pierre,
I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with PBKDF2? Or
other iterated stretching algorithms similar to PBKDF2?The algos recommended to use with PBKDF2.
I just updated the RFC to include a description of the non-obvious
parameters ($password isn't described). I also included a bit on
algorithm selection in there.
Take a peak and let me know if that satisfies what you were looking
for, or if it needs to be expanded further.
Thanks again,
Anthony
Bumping this for a last call RFC.
It will be 2 weeks on Monday since the proposal, and since there's not
been a lot of traffic on the discussion, I'm planning on putting it up
to a vote at that time (unless there are any major objections raised).
So if anyone wants to comment prior to the vote, please do so!
https://wiki.php.net/rfc/hash_pbkdf2
Anthony
Pierre,
I would update the RFC with the current available algorithms or
recommended to be used (depending on the usage or goal).When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with PBKDF2? Or
other iterated stretching algorithms similar to PBKDF2?The algos recommended to use with PBKDF2.
I just updated the RFC to include a description of the non-obvious
parameters ($password isn't described). I also included a bit on
algorithm selection in there.Take a peak and let me know if that satisfies what you were looking
for, or if it needs to be expanded further.Thanks again,
Anthony
hi,
Bumping this for a last call RFC.
It will be 2 weeks on Monday since the proposal, and since there's not
been a lot of traffic on the discussion, I'm planning on putting it up
to a vote at that time (unless there are any major objections raised).So if anyone wants to comment prior to the vote, please do so!
Quick reminder, it will be -1 from here if it targets 5.4, for all the
reasons I have been repeatedly explaining.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
Quick reminder, it will be -1 from here if it targets 5.4, for all the
reasons I have been repeatedly explaining.
I've updated the RFC to indicate such (that it's only targeting master (5.5)).
Thanks,
Anthony
Hi Anthony,
i think your RFC is very good!
I like the idea to have PBKDF2 implementation that is able to act, at
the same time, as secure hash value generator (without the length
parameter) and as key derivation function (with the length parameter).
I think we should be consistent with the API of Hash functions of PHP
and use the raw_output = false to generate hex string and raw_output =
true to generate binary output.
If folks need to convert the output to Base64 they can easily use
base64_encode($output) where $output is generated with raw_output =
true.
I don't think this is a big deal.
I also agree to insert this function in PHP 5.4, actually in this
implementation we reused other hash functions of PHP and the tests for
PBKDF2 are fully specified in PKCS #5 test vectors that you used in
your patch test.
Very nice job!
Regards,
Enrico
2012/6/19 Anthony Ferrara ircmaxell@gmail.com:
Hello all,
Since there wasn't that much traffic on the draft version of the RFC,
I've moved it into Proposed.https://wiki.php.net/rfc/hash_pbkdf2
What are your thoughts?
Thanks,
Anthony
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't have at least 16 characters (128 bits), throw error
internally this calls:
hash_pbkdf2('sha1', $password, $salt, 1000);
My point being that:
$hash = hash_password('1234', 'my'. $password[1] .
'super-long-salt-secret');
Gives good enough security 80% of use cases and is simpler then:
$hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] .
'super-long-salt-secret', 1000);
Developers will still use sha1 or md5 because they are so simple.
Jonathan,
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
Checkout the other thread about adding a simple password API.
As far as implementing that as well, I don't care for it. Basically,
the reason is that it limits the algorithms that can be called by
hash_password. Specifically scrypt would not be possible, because it
has more parameters than that.
My point being that:
$hash = hash_password('1234', 'my'. $password[1] .
'super-long-salt-secret');Gives good enough security 80% of use cases and is simpler then:
$hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] .
'super-long-salt-secret', 1000);Developers will still use sha1 or md5 because they are so simple.
The goal of this API addition is not to simplify anything. It's to
provide a C implementation of the PBKDF2 algorithm. The other topic
about password hashing has the simplification goal.
Anthony