Re: Adding a simple API for secure password hashing?

Alexander, > BTW, what version of PHP introduced the === comparison operator? > I guess this should become the minimum version for phpass since this is > highly desirable to use. > > http://www.php.net/manual/en/language.operators.comparison.php > does not > say anything about that. > That's been in there for quite some time... I know at least php 5.0 had it (and I'm pretty sure it was 4)... > Thank you for not including other crypt() hashes.  I fully support > starting with bcrypt only, and only adding to it if there's something > actually better, not just for the sake of giving more options to a user > who can't make an educated decision. I originally included them, but then it was pointed out that they are weaker, and I was asked *why include them*. when I couldn't answer, I pulled them... > In the same spirit, while I support your proposal to add PBKDF2 to PHP > proper, let's not add a crypt()-like hash encoding based on PBKDF2. > I'd rather not see additional weaker-than-bcrypt hash types in use. > In other words, I oppose your $pbkdf$ thing from PHP-PasswordLib. ;-) I had no plan on adding that to the core... So we're in perfect agreement there... (although in a side-lib, I don't see the harm as long as it's not default). > For that, we'd need to decide on a proper crypt() hash encoding syntax > for scrypt - something Colin chose not to do so far.  At the very least, > we'd need to know and consider his current opinion on the matter.  IIRC, > when I asked in 2010 (in March or April), his reply was that he did not > feel scrypt was mature enough for that (it was about 1 year old at the > time, since 2009). Agree. If I was to add it (I've been thinking about it), I would add it along side hash_pbkdf2 as hash_scrypt(). I would prefer waiting for the standard encoding syntax (so that we're not creating a new one) to include it in crypt(). > It might happen that we come up with another memory-hard function to use > for password hashing before there's an agreed upon hash encoding syntax > for scrypt in particular.  To me, this possibility is a reason not to > hurry with introducing such syntax for scrypt.  We also need to decide > on an approach to this: > http://www.openwall.com/lists/crypt-dev/2011/05/12/4 > (dealing with the memory requirements with concurrent authentication > requests).  Well, maybe just require relatively little memory - way more > than bcrypt, but less than what scrypt was originally designed for. Sure... > Meanwhile, I suggest that we treat scrypt just like we do PBKDF2 - > provide a native function for it as a KDF, but no crypt() hash encoding > syntax for its use for password authentication yet (even though this > might be a more relevant use of it in PHP in the long run). Again, agreed. > Maybe, but if we add scrypt proper then I see little use for Salsa20/8 > on its own. Very true. Was just a thought. > What was the reason why Salsa20 was dropped in 5.4 (it was in 5.3, but > probably not usable for scrypt because of different round count)? I don't know. I was trying to find that out but everywhere I looked turned into a dead end. Thanks, Anthony