> Hello, Hi Ricard.
> I have been looking into using the SHA256/SHA512 crypt_hash > functions, and during my testing, comparing the results with other > implementations (Python's passlib, Openssl, MySQL and C), I found > that for some passwords used, the resulting hash is different that > the ones generated by other languages/implementations, and therefore > would fail if a hash of these passwords done with Pike was then > computed/verified with another system. > > I don't know the reason of this, but it seems to fail with some > passwords, regardless of the salt or number of rounds, and both > SHA256 and SHA512 "fail", while for some other passwords it works > well. A couple of values that fail are simply "pass" and "password". The cause seems to have been the termination condition of the loop in stage 11 of crypt_hash(). The bug caused the loop to terminate early when the password length was a power of 2. > Below I attach some examples, using the mentioned failing passwords, > first in Pike, and then comparing the computation of the same hash, > using the same password/salt/rounds in other implementations, and > you can see that all the rest are the same among them, but different > from Pike. This fails also using Crypto.Password.hash(), and letting > it compute a random salt. I also tested the reference base C > implementation cited in your documentation > (https://akkadia.org/drepper/SHA-crypt.txt), and it gives the same > result as the others (and thus, different than Pike's). Thanks for the examples. They helped quite a bit. > In addition, I also found that in some cases, the random salt > contains the character "+", which the Python library I tested > doesn't 'allow' it seems, this is probably not a bug itself, but > could be taken into account for future implementations when > generating a salt, I attach here their explanation: [...] This seems to have been already fixed in Pike master. > I would like to know if this is really a bug, and if it is, if you > would be able to maybe fix it in some revision, if that's the case, > I would be interested in using the updated/corrected code ASAP, > implementing it in a module of my own perhaps. [...] Fixed in Pike 8.0 and master. > I await your response, thank you for your time. > Yours truthfully, > > Ricard Garra Oronich Thanks for the report (Pike #10137). /grubba Bill: Please make sure that this fix is in your release.
