Hi Anthony, I noticed I've made silly mistakes in previous reply. I've added little more. Even if I remove text formatting, gmail insists strange formatting. It may be hard to read...
Please disregard old one and read this. On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > > > 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? I see you and Andrey against to have E_NOTICE for password_hash(). There are only 2 persons to be correct in this thread. I don't know about IRC since I don't use it at all. However, I don't mind at all to write RFC raising E_NOTICE for password_hash() with PASSWORD_BCRYPT. > > 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 Although cryptgraphic hash functions are supposed work cryptgraphic way, but many of them are failing. This was in real world and I aware of the risk. > 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. I agree with your discussion and have no objection. I understand that it's correct in theory and real world. Even if I understand the risk, it's acceptable for me to use SHA512 to workaround password length limit as long as SHA512 and/or blowfish is considered safe by specialists. As I wrote, password length limit is decided by app developers and we are not the app developer. (BTW, I do code audit/web security check/education for living, but I'm not a cryptographer) > > 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. I agree that recent crypt() can be used securely (and reliably). I'm pointing it out that it was not, especially with pre 5.3 as you know. We know that there are many users out there still using pre 5.3. http://w3techs.com/technologies/details/pl-php/5/all > > 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. I'll strongly object returning FALSE for faulty usage. IMHO, it is as bad as using too long prefix for PASSWORD_BCRYPT. It could disable authentication completely. > > If we would like to recommend "Just use it", we may consider adding SHA512 > > to password_hash(). > > As I pointed out above, no. I'm lost here. Are you going to discuss use of SHA512 for password hashing is insecure? Blowfish is suitable for password hashing because of its "slowness". Isn't it matter of rounds? SHA is targeted by attackers and hardware cracking became common. Is this the reason? We need 72 bytes limit workaround/solution some how, but it seems you are objecting possible choices. Most developers need adequate level of security to build applications, not perfect security. Not all developers have right to decide maximum password length and how password is hashed. (e.g. Adding secret salt is still valid protection against stolen password database via SQL injection,etc. Some organizations require to add custom static slat to user defined password.) > > > 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. OK. This was too much. I'll use "recommend" or like. > > > > 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 wish I could educate users/developers "Just use password_*()". Problems are password length limit and truncation without any noticeable error. password_hash() is named "hash" and average users expect that "hash" will compute hash value from given parameter, not part of it. I agreed that leaving crypt() as it is now. I've closed the bug report as "wont fix" already. It was my original intention, in fact. I'm not sure your opinions for - password_hash() truncation behavior - What to do to accept password longer than 72 bytes Could you give your opinion for these? My opinions are - Raise E_NOTICE for too long password. (Error only, returns result with the truncated password) - Make a documentation issue. Recommend prehash. Alternatively, add SHA512 hash with large enough rounds. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
