Pierre, > Back then MD5 alone was all nice and shiny. So no, it is not possible > to be forward compatible.
By forward compatible, if you mean able to support any new algo, I think this is forward compatible. The options array allows for new implementations to implement whatever options they need. If you mean 100% compatibility, then no. That's not possible (due to storage requirements, etc). But the API would stay the same... >> 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. This RFC does not intend to replace crypt(). It is intended to be a reasonably thin wrapper around it to make it easier to use for the average use case. Crypt() will still be there, and will still be encouraged for the use-cases that it makes sense for (portability, etc). This just attempts to solve the problem for the vast majority of users. In fact, the exposed password_make_salt() should make it easier for developers to use crypt: $hash = crypt($pass, "$6$" . password_make_salt(16)); Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
