On Mon, Jun 18, 2012 at 7:14 PM, Anthony Ferrara wrote:
> 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 all
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Enrico
> I like your idea to offer a wrapper of crypt() with a better API
> (actually I used this approach in the ZF2 project:
> https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Password/Bcrypt.php).
Yeah, crypt() is really nice, and offers a lot of good things out of
the box.
2012/6/18 Anthony Ferrara :
>
> That's why the crypt() return format was designed. All of the options
> that are needed to validate the hash (algorithm, cost parameter, salt,
> etc) are fit right into the outputted string.
>
> I'd suggest that's what's done here. In fact, I'd make the functions
> j
Hello all,
I'd like to request commit karma for php-src trunk. Among the things
I'd like to commit include https://github.com/php/php-src/pull/108
Let me know if there's anything else that I need to do or provide.
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
Pierre,
> There is sadly only state-of-art-right-now password hashing methods.
> We have to keep that in mind :)
That's why the crypt() return format was designed. All of the options
that are needed to validate the hash (algorithm, cost parameter, salt,
etc) are fit right into the outputted strin
On 18.06.2012, at 19:42, Pierre Joye wrote:
It is BSD-licensed, so we can easily bundle it with PHP
>>>
>>> Maybe nice to have in pecl.'
>>
>> Sure, that's an option, but pecl won't help php to have default
>> "state-of-art" password hashing toolset ;)
>
> There is sadly only state-of-ar
hi,
On Mon, Jun 18, 2012 at 11:06 AM, Alexey Zakhlestin wrote:
> The post says, that SCrypt is better, because it is way harder to solve.
> Bcrypt requires a lot of CPU, but SCrypt requires a lot of CPU + a lot of RAM
Ah right, I read it the other way 'round...
>>> It is BSD-licensed, so we ca
On 18.06.2012, at 1:54, Pierre Joye wrote:
>> I guess SCrypt binding could be implemented.
>> http://www.tarsnap.com/scrypt.html
>
> Using yet another dependency for that? Not good.
That's easier and safer than implementing this on our own.
>
>> That's the best available option at the moment.
