Re: [kitten] Non-Password Password Change

["Henry B (Hank) Hotz, CISSP" <[e-mail]>]

> On Oct 15, 2015, at 2:51 PM, Greg Hudson <[e-mail]> wrote:
> 
> On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote:
>> There’s been work on improved password change protocols, but I’m not sure how much actually completed. I also remember once suggesting that loading a KDB entry from a keytab file would be useful, at least for handling cross-realm principals.
> 
> I believe the most recent work is:
> 
>    https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08
> 
> I vaguely recall an explicit decision not to continue with that work
> because no one believed they were likely to implement it.

I see a set_keys() operation in there. I don’t think I’m likely to implement it though.

>> Are there any password change protocols where you can supply the enctype and a key instead of a text password?
> 
> This is probably obvious, but any such facility allows the client to
> circumvent password policies, and therefore usually require special
> permissions.

Given PKINIT and FAST/OTP, all you need is a policy which says NO-PASSWORDS. ;-)

> I believe you are correct that in current implementations, the only way
> to do that is via implementation-specific admin interfaces.
> 
> Another mode I would find interesting is one where the server makes up a
> new password and tells you what it is.  I don't know if it would get
> much use (I've never seen passwords managed that way in any
> environment), but it seems like a reasonable way to mitigate risk.

I once built a service which chose users’ passwords and emailed them to them. I didn’t have to implement any set/change password functionality and the reset function was dead simple.

The above draft supports it. What would be nice is if you could update application servers' keytabs *before* the kdc started issuing tickets with the new keys.


Personal:  [e-mail]
Business: [e-mail]