On Wed, Jun 27, 2012 at 07:51:38AM -0400, Anthony Ferrara wrote: > > > Note: _if_ you ask for a portable hash. What else should it do if you > > ask it for just that? > > That's a fair point. I guess since the adoption of 5.3, and the fact > that 5.2 is dead (yet alone php4), has me thinking that "portable" > means something different today than it did then...
Regarding "5.2 is dead (yet alone php4)", it's wishful thinking. Sure, these have known vulnerabilities and such, yet they're still widely used. For PHP 3, I agree - it's in fact dead. I am going to drop support for PHP 3 in the very next revision of first generation phpass. 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. > >> > So for modern versions > >> > of PHP (5.3+), it produces an unnecessarily weak hash. > > > > For modern versions of PHP, if you don't require portability of hashes > > to older versions, don't ask it for a portable hash. > > That's fair. Perhaps the documentation needs updating to indicate that > *portable* really just means compatibility with php <= 5.2... Yes, I may do that. The website mentions that on PHP 5.3.0+ the fallback never occurs, but it does not say when not to force the use of portable hashes. (In a new revision, the minimum version for never-fallback will likely be 5.3.7 as I am going to add a check for CVE-2011-2483.) > > Of course, new PHP apps that will depend on your new API won't run on > > older versions of PHP by definition, so they could assume bcrypt is > > available. A concern, though, is that by the time major web apps would > > be able to assume a recent enough version of PHP (with this new API) > > we'll prefer to use a password hashing method with more than one > > configurable parameter (not just one "cost" setting), so we may want to > > design the API with that in mind. > > That's a very good point. And it's already designed into the API. I'll take a look once I have a moment. > Right now, it only implements one algorithm in the core, but the > switches and options are all there to support multiple. I just didn't > see any solid reason to include the other (slightly less favored) > crypt() hashes available today (SHA512 for example). 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. 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. ;-) > But it's designed > so that they can be added easily. I know there's talk floating around > the list with respect to adding scrypt support into core. If that > happens, it would definitely be added to the implementation. 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). 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. 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). BTW, for scrypt, it would be highly desirable to include the version of it that uses SSE2 intrinsics in the Salsa20/8 implementation (for use on systems capable of SSE2, indeed). While on x86-64 SSE2 is implied, I imagine that for 32-bit x86 builds of PHP we could choose to add runtime CPU detection and choice between two implementations. > > Additionally, I was/am going to experiment with implementing a decent > > KDF in PHP, but also considering its native reimplementation at the same > > time (for inclusion in PHP proper, etc.) That way, we could have hashes > > that are both portable (to older versions of PHP, to other scripting > > languages, etc.) and efficient. My expectation is that when implemented > > in a scripting language (using a widely-available crypto primitive like > > SHA-512 or AES), they could be somewhere inbetween bcrypt and scrypt in > > terms of cost of attack - and when reimplemented natively, they could be > > approaching scrypt (although Colin's choice of Salsa20/8 core for the > > crypto primitive was not arbitrary, and unfortunately we don't have that > > in PHP). I feel that there's room for exactly one such would-be > > de-facto standard "scripting KDF", and I might be in a position to set > > this standard due to phpass (this new thing could be a next generation > > phpass). But I haven't decided on this yet, I'd need to experiment > > first, and I don't like to be rushed. ;-) > > No rush at all. I like the concept though. Would it be worth while to > add an implementation of salsa20/8 to the core? Maybe, but if we add scrypt proper then I see little use for Salsa20/8 on its own. 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)? > Well, part of the reason for this API, is that it appears that the > majority of developers either aren't willing to use a library, or > don't know it exists (even though it's very easy to find if you try). Fair enough. > Additionally, I would think there would need to be a vetting period > for a new KDF like this (for review, and trial implementations and > such) before it would be considered "stronger" than bcrypt. If that's > the case, then the core implementation would work fine. You implement > the new KDF in a library. It goes through vetting and testing. if all > is good, when it's mature it can be added back into core in this API. Sounds right. Thanks, Alexander -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
