Lev leventelist@gmail.com wrote:
Yes, that was a bit odd. Same password, different hash. Even with verify tool, there was mismatch. So I decided to go for SHA512, without encryption.
Using user@domain as your ID solved your problem, and this side issue of which hash scheme you're using is probably irrelevant.
You misunderstand what {SHA512-CRYPT} does compared with {SHA512}. It is normal to get a different hash with the same password when you regenerate the hash because a different random salt was chosen (the part between the '$6$' and the next '$') -- it used as part of the hash computation.
{SHA512} is a straight saltless hash -- the same password maps to the same hash. This makes it prone to dictionary attacks (i.e. pre-generated tables of plaintext/hash values).
If you support both schemes, SHA512-CRYPT is much stronger.
Joseph Tam jtam.home@gmail.com
On Sun, 16 Jul 2017 14:20:27 -0700 (PDT) Joseph Tam jtam.home@gmail.com wrote:
Using user@domain as your ID solved your problem, and this side issue of which hash scheme you're using is probably irrelevant.
You misunderstand what {SHA512-CRYPT} does compared with {SHA512}. It is normal to get a different hash with the same password when you regenerate the hash because a different random salt was chosen (the part between the '$6$' and the next '$') -- it used as part of the hash computation.
{SHA512} is a straight saltless hash -- the same password maps to the same hash. This makes it prone to dictionary attacks (i.e. pre-generated tables of plaintext/hash values).
If you support both schemes, SHA512-CRYPT is much stronger.
Thanks again. I'll retry it with SHA512-CRYPT. You are right, I didn't know how that computation worked.
Levente
participants (2)
-
Joseph Tam
-
Lev