Avoiding Pre-Auth/Auth Principal State Disclosure

[Robbie Harwood]

Chris Hecker <checker at d6.com> writes:

> On Tue, Jun 30, 2020 at 23:01 Eric Hattemer <ehatteme at 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’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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20200701/7bf6821b/attachment.bin