Pierre, Getting back to the PASSWORD_DEFAULT discussion...
I know you didn't like PASSWORD_MOST_SECURE. So what about keeping PASSWORD_DEFAULT as a moving target, documented, and just making the second parameter (algo) to password_hash required? That way users could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT. That way, over time, PASSWORD_DEFAULT could be updated, and it would be documented that it would change. But it would require them to understand that it could change... Would that satisfy your issues? Thanks, Anthony On Wed, Jun 27, 2012 at 8:12 AM, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > On Wed, Jun 27, 2012 at 1:49 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt> wrote: >> Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye <pierre....@gmail.com> >> escreveu: >> >> >>> That's exactly what I meant, having a changing default in this may >>> force code change during php updates. I'm not in favour of having such >>> default. >>> >> >> This would not require any code changes after updates. >> >> As I understand, hashes computed with the old default method could still be >> checked without any modification as the hash itself stores information about >> the method. > > That's only about one relatively simple use case where only PHP would > be involved or crypt-like implemenation. For any other and rather > common cases, it won't. I do not think a default should be implemented > and actually let the user knows what he uses and what he is doing. > That's one argument after all and clears all possible caveats. > > 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
