Wow, thanks for taking the time for the detailed response! I will digest
this and see if I still have questions.
Chris
On Thu, Jul 2, 2020 at 10:45 Greg Hudson wrote:
> On 7/1/20 3:55 PM, Chris Hecker wrote:
> >> For example, if we treated single-component principals as users,
> > anyone with
On 7/1/20 3:55 PM, Chris Hecker wrote:
>> 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.
>
>
> 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 treat
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 invali
Chris Hecker writes:
> On Tue, Jun 30, 2020 at 23:01 Eric Hattemer 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
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.
Chris
On Tue, Jun 30, 2020 at 23:01 Eric Hattemer
