dovecot - Jul 2017 - SQLite user database

Lev <leventelist at 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 at 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 at gmail.com>

On Sun, 16 Jul 2017 14:20:27 -0700 (PDT)
Joseph Tam <jtam.home at gmail.com> wrote:
> Using user at 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