Pierre, >> 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.
Well, the argument could be made that if you need portability in that respect, that you should be using `crypt()` or the other library directly. This API is designed for the common use-case that impacts 99.9% of developers, where their applications will be the only ones accessing the passwords. And even if in the future they need to access it from a different system entirely (python for example), we're only implementing standard algorithms. So there should be a python binding available to verify (and hash) those passwords. This won't take the place of crypt() or other libraries. It's only there to solve the lowest common denominator in a dirt simple way. I think removing the default (and forcing an algorithm specification) kind-of defeats that point a little bit. It's not the end of the world, and I could possibly be convinced, but I'm skeptical. As for the issue you raised, I think that could be handled in the documentation. Perhaps something to the effect of: > PASSWORD_DEFAULT - This is the default algorithm that password_hash will use > if none is specified. Note that this is designed to change over time as newer > and stronger algorithms are implemented. If you need to stay with a single > algorithm (for portability or other reasons), it's recommended to always > specify the algorithm in the function call. 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? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
