Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 May 2019 14:16:00 +0200
From: Solar Designer <>
Subject: Re: SSHA256 (32bit hash, 32bit salt)


On Mon, May 27, 2019 at 07:01:18PM +1000, Jason Thomas wrote:
> Theses hashes came from atmail, or more specifically atmailcloud. Through
> the admin web API.

Thanks.  Perhaps someone (you?) should contact them and ask them to
migrate to proper password hashes such as bcrypt, (ye)scrypt, or Argon2.

Meanwhile, we've added a slightly more elaborate revision of the Perl
script as run/ to bleeding-jumbo.


Please feel free to add this as a thin format as well.  Yes, these
{SSHA256} hashes might not match what another project might call the
same - e.g., their salt size appears to be inconsistent with LDAP's
{SSHA} hashes - but we already have multiple formats recognize the same
strings as potentially theirs (e.g., many would recognize 32 hex
digits), so I think it's OK.  You might want to call this format e.g.
atmail-ssha256 or ssha256-atmail.

Maybe you could also add ability to base64-decode hashes and salts, and
extract their portions into $s or such accordingly, to dynamic formats
in general - ideally, also usable via command-line "dynamic scripting".
Maybe this would eliminate the need for having some thin formats in C,
instead defining them in a .conf file?

As I understand, currently dynamic formats are able to base64-encode
intermediate hashes before further hashing (as it's sometimes a step in
third-party hashes that we need to support), but it requires that its
input hashes be in hex and salts in plaintext or hex.  This is limiting
its convenient use, sometimes requiring re-encoding as we see here.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.