pkinit and passwords issues
Nicolas.Williams at sun.com
Fri Feb 12 18:16:54 EST 2010
On Fri, Feb 12, 2010 at 05:57:32PM -0500, Jeffrey Altman wrote:
> On 2/11/2010 6:43 PM, Sam Hartman wrote:
> > 2) There is no valid password. In which, the password should not be set
> > to expire.
> Setting a random password and setting it to never expire results in
> there being a password that can be brute forced over a long period of
> time and used as a backdoor. It would be much better if a property on
> the principal simply indicated "no password authentication permitted"
> and be done with it.
It's not just that. A customer might want to be able to enforce a
policy that only PKINIT is used (coupled, for example, with a smartcard
key/cert provisioning process to ensure that smartcards are used).
> I recommend a table with an entry for each loaded pre-auth mechanism
> that would be initialized by the mechanism.
I'm not sure I follow. I think what we need is a per-user pre-auth
policy. Because pre-auth is an open set, the manner in which policy can
be specified per-principal needs to be extensible. Either a TL data scheme
or per-policy equivalent seem appropriate.
> Something else to think about is "can a password change authenticated by
> a PKINIT work?" Has anyone tried this? I'm not sure the existing
> password change mechanism on the client side can support this from a
> UI perspective.
True. Changing an expired password using PKINIT could (would) obviate
the need to prompt for the old password, for example.
More information about the krbdev