Re: [DRAFT RFC] Adding Simplified Password Hashing API

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