[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112145322.GK5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 09:53:23 -0500
From: Rich Felker <dalias@...c.org>
To: Lukas Tribus <lukas@...i.eu>
Cc: musl@...ts.openwall.com
Subject: Re: crypt: unsupported hash behavior
On Thu, Nov 12, 2026 at 02:04:24PM +0100, Lukas Tribus wrote:
> Hello,
>
> I'm aware of the short term intention to modify the crypt() error
> token from * to *0 mimicking libxcrypt and the long term intention of
> returning NULL (which is what RHEL9/10 already does because libxcrypt
> is build with --disable-failure-tokens), both changes I think are
> great.
>
> In haproxy, we use crypt/crypt_r for authentication purposes and at
> startup we check whether the hashes are supported by passing an empty
> password with the salt to crypt() to determine whether the hash type
> is supported:
>
> hash = crypt("", args[cur_arg + 1]);
> if (!hash || hash[0] == '*') {
> ha_alert("parsing [%s:%d]: the encrypted password used for user '%s'
> is not supported by crypt(3).\n",
> file, linenum, newuser->user);
> }
>
> We used to just check for NULL which worked fine in RHEL9/10 due to
> libxcrypt--disable-failure-tokens; we added a check for * the other
> day, which makes this work in non-RHEL glibc/libxcrypt distribution
> like Debian.
>
> AFAIK returning an error when a unknown hash type is a implementation
> detail of glibc crypt/libxcrypt.
>
> It does not happen in musl's crypt.
>
> My question is whether it would be possible to implement the stricter
> libxcrypt behavior even though there is no "contract" (POSIX or
> otherwise) requiring it. As this is already the case in libxcrypt and
> likely in the previous glibc implementation, I don't think we would be
> upsetting applications.
Yes, I've suggested we could remove the support for noncanonical DES
salts without breaking existing hashes that might exist in the wild by
doing something like, at the end of descrypt:
if (has_bad_characters) {
if (strcmp(output,setting)) return 0;
else return output;
}
Note that the noncanonical DES hashes are already stochastically
buggy. It's improbable but possibe for descrypt(password,"$n") to
produce a DES hash where the first few characters of the hash mimic a
valid "$n$" pattern, which when you pass the hash back to crypt, will
result in a different hash function getting used, thereby locking the
user out.
Rich
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.
