hi, On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt> wrote: > Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara <ircmax...@gmail.com> > escreveu: > > >> Actually, now that I'm talking that out, perhaps the way to do it >> would be to specify the default algorithm in a php.ini parameter >> instead of the constant? That way the API can stay the same, but gives >> people more control over the default creation... Then again, maybe >> not. >> >> Thoughts? > > > I don't see any advantage in adding complexity through another level of > indirection. If people want control over the default their application uses, > they can just use a constant they define.
And people will have to, as I described it earlier, and see below. > That said, I think the default algorithm should provide sufficient > guarantees to enable it to be used in a forward compatible fashion. Back then MD5 alone was all nice and shiny. So no, it is not possible to be forward compatible. > For > instance, if the default hash at one point consumes n bytes, then it may be > backwards incompatible to change to use more than n bytes as at that point > you may need a larger database field. So it should be documented with future It is not about size but ability to use the password across many applications. The days were only PHP were involved are behind us. yes, crypt may (in some extend) allows that, but this RFC purpose is to replace it, for a more developer friendly API. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
