Re: Avoiding Pre-Auth/Auth Principal State Disclosure

Robbie Harwood <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Message-ID <[email protected]>
Chris Hecker <[email protected]> writes:

> On Tue, Jun 30, 2020 at 23:01 Eric Hattemer <[email protected]> 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’s a todo item to clean those up at some
> point?  I can’t remember the one or two I found since it was a while
> 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

________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
signature.asc (application/pgp-signature, 832 B)
-----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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.