Re: Avoiding Pre-Auth/Auth Principal State Disclosure

> For example, if we treated single-component principals as users,
anyone with a user/admin principal (or user/root, which has no status in
the code but is a common convention for elevated access) would probably
still be detectable by an attacker.

Not sure I follow this, why wouldn’t they be treated like a normal princ if
we had this obscurity feature?  I remember assuming vague errors would fix
this but then discovering it didn’t, which was surprising.  I build my KDC
myself so I wasn’t worried about that part, I just was surprised it wasn’t
possible.

Chris


On Wed, Jul 1, 2020 at 12:39 Greg Hudson <[email protected]> wrote:

> On 7/1/20 1:53 AM, Eric Hattemer wrote:
> > 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 don't have a setting like that.  The closest nod we have in the code
> to this desire is a "vague errors" setting for the KDC, which can only
> be turned on at compile time (or via ptrace, I guess) and causes the KDC
> to yield generic errors instead of useful ones.  But that setting still
> allows an attacker to easily distinguish between "client principal
> requires preauth" and "client principal not found".
>
> Because the Kerberos principal namespace isn't formally divided between
> users and services, any obscurity feature would probably have some edge
> cases.  For example, if we treated single-component principals as users,
> anyone with a user/admin principal (or user/root, which has no status in
> the code but is a common convention for elevated access) would probably
> still be detectable by an attacker.
> ________________________________________________
> Kerberos mailing list           [email protected]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos