[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112155313.GL5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 10:53:13 -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 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.
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.
