[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20261107221943.GJ23438@brightrain.aerifal.cx>
Date: Sat, 7 Nov 2026 17:19:43 -0500
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: OpenSSH password auth bypass analysis
On Sat, Nov 07, 2026 at 11:00:13PM +0100, Thorsten Glaser wrote:
> On Sat, 7 Nov 2026, Rich Felker wrote:
>
> >But we could do the fallback only when validating (the input salt has
> >a hash with it) not when generating new passwords (setting part only).
>
> This… does not read well on first pass.
>
> While, yes, all straightforward applications would do that,
> there may exist applications that only pass the setting part
> when validating.
A program doing validating can't know what part is the setting without
hard-coding what hash types it supports. That does not seem like a
reasonable behavior.
In any case it would still get an unmatchable result, just not one
unique to the password attempted.
> Something that has (documented) insight into the hashes.
> Something… like PHP’s wrapper around libc’s crypt(3), perhaps
> (I have not looked, but this sounds *exactly* like what PHP
> would do, either in an older version, or as a (newer) response
> to some perceived security issue).
>
> This has the chance to backfire in that only the first eight
> bytes will be tested. I’d personally not do that.
I don't follow. What you would have is:
crypt(overlong_password,sha_setting_only) = "*0"
crypt(overlong_password,sha_full_hash) = string_unique_to_pass
This would ensure that crypt(overlong_password,another_users_hash)
produces a string that could never match any form of "no password
access available" string for the target user.
While also ensuring that attempting to set a password of unsupported
length still gives back a failure token.
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.
