[38785] in Kerberos
Re: Avoiding Pre-Auth/Auth Principal State Disclosure
daemon@ATHENA.MIT.EDU (Robbie Harwood)
Wed Jul 1 14:28:03 2020
From: Robbie Harwood <rharwood@redhat.com>
To: Chris Hecker <checker@d6.com>, Eric Hattemer <ehatteme@usc.edu>
In-Reply-To: <CAOdMLc2koDuuBW+98Ssa3gnnMPRh8QwxZ8k6kD1bhnXPg4x9bQ@mail.gmail.com>
Date: Wed, 01 Jul 2020 14:24:52 -0400
Message-ID: <jlgsgebf5zf.fsf@redhat.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============7243776704810885366=="
Errors-To: kerberos-bounces@mit.edu
--===============7243776704810885366==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha512; protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Chris Hecker <checker@d6.com> writes:
> On Tue, Jun 30, 2020 at 23:01 Eric Hattemer <ehatteme@usc.edu> wrote:
>
>> If you run a client like kinit and ask for a principal with
>> REQUIRES_PRE_AUTH and a disabled/pw_expired/locked-out state, or
>> request a principal that doesn't exist, you aren't asked for a
>> password and get an immediate response with the status of the
>> account. Is there a way to avoid this behavior? People have created
>> hacking toolkits that try every possible username to download the
>> list of usernames in the database and their state.
>>
>> I know pre-auth is a special case where you'd need to provide a
>> plausible challenge for non-existent accounts. But is there maybe a
>> setting to treat unknown principals as if they had pre-auth disabled,
>> request a password, and just send back invalid password / encryption
>> failed no matter what?
>>
>> We were trying to implement an authentication proxy module that uses
>> Kerberos, and we wanted to only disclose an account was disabled if
>> the user typed in the correct password. But the only case we could
>> make work was if the account was expired (different from pw_expired).
>
> There are actually a bunch of places that leak information about valid
> princs, I wonder if there=E2=80=99s a todo item to clean those up at some
> point? I can=E2=80=99t remember the one or two I found since it was a wh=
ile
> ago but I posted it to the list as well.
In my opinion, it's not generally a good idea to consider usernames
private information. Typically they're predictable and should pale in
comparison to password strength anyway.
I'd additionally suggest turning on preauth for all user principals.
Thanks,
--Robbie
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl781PQACgkQJTL5F2qV
pEKi+xAAwk943legfZsDxlQ2qprW+rrcXnu78DgvfxSoIzLmRA1Is+GbqE3981fI
qWOt1xn0tsFzsSi1el06n2E9ouvyRH6ueQlx6u/y4FCfKallAAQxRdZ2Pj1PhDHo
OU3FtHrdqD6J94OXm+4EF0unakbEIQ7VLg/aITZobzPrd+ZanUILjmoLgmExGr2e
pOsumnvRf2nLbIg0hs62pUij+deBZmZRwwizN7mjveF8LE3QijXBmK6L+n/em4aH
AAZ957obz9iwb1WHyKnPpm0VBOyfnkrfPeGst4BVAK7ULdeBMveFNyFp0qdEke1/
XL2jlkEKZqvE+L6GxxRKwU4d1yWrQX+i7dYt1VYAj4bHwsrlC3+O3j5BdG5G7KAr
DOU24QHUv4+7KRXMdGV6juG0Z0L3t5W/a3kGjTt/dnD+KKfB+tUJCA6KkXoObLwK
/s4LQ78rZb/RwFynBFJW6g1ABZfurZCB2U4S59EFh4t//uWmejXinw5bkqEZLCnw
KH6n/DFBypeysY7nDzf6tHlzXRHoVG0uzdphLVrI6IFtEMakCE+c+b1fmrfbgXtA
sQ+U5PzcezIPbqpcdxRrNH7kopuHV6hXYf3c8takzNqRg9JFIbTlURDBBPvKrezm
cRJOYzmocVuWdMBnS3/hCLwFZHHlo2OEUYa/qQvT0rc0z1EGr+g=
=svdU
-----END PGP SIGNATURE-----
--=-=-=--
--===============7243776704810885366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============7243776704810885366==--
