Yasuo, > E_NOTICE for password larger than 72 is mandatory. Current password_hash() > works without any sign of problem even if it may not be working as > authentication. > I'll add E_NOTICE as bug fix if there aren't any more comments.
Could you please not. I have asked you to draft an RFC to justify what you intend to do (documentation, errors, etc) so that we may discuss it better. There is not a single person in this thread who has said "I think a notice is a good idea" except you. Yet you insist on just adding it as a "bug fix". Could you please just slow down, and write out the explanations so that we can have a meangingful discussion instead of just rushing through to commit ignoring what everyone is saying? > However, Using multiple hashes for better security is common technique. > An example is SSL. So I would not say one should not. Especially when there > is a limitation. TLS 1.0 (SSL) used a very specific construction of PRF<MD5>(secret1, label + seed) XOR PRF<SHA1>(secret2, label + seed). This is very much not "using multiple hashes", but using 2 different PRF (pseudo-random functions) and xoring them together. The end result should be resistent to cryptoanalysis or attacks that only target one of the hash functions. However, TLS 1.2 removed that construction and uses the PRF based on SHA-256 alone. Why? As it turns out, it's not based in science at all, and can be proven faulty. Here's a quick proof: HASH_FUNC_A - A secure cryptographic hash function (resistent to collisions, pre-image attacks and 2nd pre-image attacks, ex: SHA-256) HASH_FUNC_B - Defined as HASH_FUNC_A XOR C (for some arbitrary constant C). Since HASH_FUNC_A is secure, HASH_FUNC_B is secure as well (since xoring with an arbitrary constant changes none of its properties). However, HASH_FUNC_A XOR HASH_FUNC_B will always produce C. Proving that XOR of two arbitrary hash functions isn't necessarily secure. More information: http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf Now, if all you care about is pre-image resistance, then H1(H2(x)) appears to be secure. And if we assume that H1() and H2() are secure functions, it is. However, that's a tricky assumption to make. For example, any collisions in H2() automatically become collisions in H1() (incidentally, this was the reason PBKDF2 replaced PBKDF1). So that effectively means that the collision resistance of H1(H2(x)) is at least as weak as the weakest hash function (potentially weaker). But we said that all we care about is pre-image resistance, so why does that matter? Because in the end, we don't just care about pre-image resistance. We also do care about collision resistance (though to a lesser degree for password storage). Because with the hash, if an attacker can generate a collision, they can use that to login to your system. Yes, that didn't leak the original password (and hence other systems may be safe), but it did let him compromise you. In practice, this isn't very likely (as SHA-512 is a strong function with no known collisions, nor decent attack against it). But in terms of recommending crypto to the general public, "isn't very likely" is the wrong way to make recommendations. > In old days, crypt() was unusable securely. There are many users/developers > that No, crypt() was perfectly able to be used securely. The password_hash apis prove that. Many didn't use it securely, but that didn't mean it isn't secure. > are used to have static slat. Code like below disables authentication > completely. > > password_hash(hash('sha512', SOME_SECRET_SALT).$password, DEFAULT); > > This should be prevented. (I would like to prevent it by raising E_NOTICE > error) And a E_NOTICE will prevent nothing. If you *really* want to prevent it, raise a warning and return false from the hash function. But that's not possible without a MASSIVE BC break. Hence why I'm recommending that you open an RFC on it. > If we would like to recommend "Just use it", we may consider adding SHA512 > to password_hash(). As I pointed out above, no. > I wrote > > "Use of <function>crypt</function> is deprecated." > > not > > "crypt() is deprecated". I didn't mean crypt() function deprecation. If it's > confusing, I don't mind at all to rewrite it. > BTW, what part is wrong? "use of crypt is deprecated" is the same as saying "crypt() is deprecated". That word has very specific and special meaning. > Adding fixed salt was > common since crypt() was not good enough used to be. In addition, maximum > password length > is not decided by us, but decided by app developers. Therefore, we are > better to provide/explain > workaround for password_hash() limitation. And as I've said before, the way to combat that is with education. > I'm not closely following doc commit. It seems my commit was modified. It wasn't modified. It was reverted. That warning that you cite has existed for 6 months: https://bugs.php.net/bug.php?id=66564 Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
