[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112180852.GO5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 13:08:52 -0500
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx+linux-man@...nel.org>
Cc: Vincent Lefevre <vincent@...c17.net>,
Alejandro Colomar <alx@...nel.org>, linux-man@...r.kernel.org,
libc-alpha@...rceware.org, Walter Harms <wharms@....de>,
~hallyn/shadow@...ts.sr.ht, musl@...ts.openwall.com
Subject: Re: Re: [PATCH v1] man/man3/crypt.3: These functions accept
many algorithms, not only DES
On Thu, Nov 12, 2026 at 03:58:30PM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> > Date: 2026-11-12 09:43:49-0500
> > From: Rich Felker <dalias@...c.org>
> >
> [...]
> > > But is the POSIX specification really useful for applications?
> >
> > Yes. It tells you enough to validate a password for authentication
> > purposes:
> >
> > const char *result = crypt(password, hash);
> > if (result && strcmp(result, hash)==0) {
> > /* password validated */
> > }
>
> Is this really specified by POSIX?
>
> Unless I'm missing something, I only see something about it in EXAMPLES,
> which is non-normative, and it doesn't even explain that this is the
> only way to do it correctly, but rather as a possible example.
Indeed it's what I'd call "underspecified", but it's clear from the
example that this is the intended usage.
> Notably,
> I don't find any text that says that passing a different hash as salt
> could potentially result in a hash that matches the stored hash.
The lack of specifying anything about whether that's possible doesn't
mean you can assume it's not.
> That is, I don't see any text (normative or non-normative) in the POSIX
> specification that implies this:
>
> When comparing a password against an existing hash, that
> hash (and no other) must be passed as salt. If and only
> if salt compares equal (see streq(3)) to the returned
> string, the password matches the existing hash specified
> by salt.
>
> The example is useful, but I'd say it's not enough. I think the example
> should contain wording like that one above (which we're discussing in
> the other thread for the manual page).
It says that the hash is a function of the password and the salt
characters. So obviously, if the password is correct,
strcmp(hash,crypt(pass,hash))==0. Whether it's nonzero for other
values of pass depends on the degree to which the hash is
collision-free, which is of course implementation-defined but needs to
be good in order to have any reasonable security properties.
Whether another hash can be passed to setting without risking
collisions is just not something that's specified, so you can't assume
it. It should be noted that the APPLICATION USAGE text mentions:
"Several implementations offer extensions via characters outside
of the set specified for the salt argument for specifying
alternative algorithms; while not portable, these extensions may
offer better security."
You do not need a specification to tell you that passing the wrong
hash as setting is unsafe. You only need to look at the scope of
implementation choices allowed and consider whether they would admit
anything that would make it unsafe. And they do.
As an aside, can we please remove the language using nonstandard
gnulib functions (streq) that are not part of any standard library?
This is not doing anyone a service. Experienced C programmers will
understand it as essentially pseudocode and write something correct
themselves, but novices will be confused why their code doesn't work.
I assume you have some sort of thing against strcmp, but that kind of
polemic treatment does not belong in descriptive documentation.
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.
