[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112155348.GM5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 10:53:49 -0500
From: Rich Felker <dalias@...c.org>
To: Lukas Tribus <lukas@...i.eu>
Cc: musl@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Subject: Re: crypt: unsupported hash behavior
On Thu, Nov 12, 2026 at 10:53:13AM -0500, Rich Felker wrote:
> On Thu, Nov 12, 2026 at 09:53:23AM -0500, Rich Felker wrote:
> > 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.
>
> Patch attached. Should we apply this now? I think it's probably a good
> idea. CC'ing Solar for input.
And actually attached now.
View attachment "0001-crypt-drop-support-for-non-strict-des-salts-in-new-h.patch" of type "text/plain" (2660 bytes)
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.
