Re: disable KADM5_PASS_REUSE error case?
Remember, policies are now extensible. So you could add a bit in the *policy* that says that it's OK for a user to change the password to one used previously. OR, we might extend *principals* to say this. Chris' use case is for password resets, so setting a flag in the principal when resetting its password, then resetting that flag upon password change would suffice. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: disable KADM5_PASS_REUSE error case?
> We could introduce some kind of opt-in global configuration for the > more consistent meaning; I'm just not sure if it's worth the code > and documentation footprint. Yeah, seems questionable. Bummer about the 0 being 1, though. Chris On 2013-06-19 21:25, Greg Hudson wrote: > On 06/19/2013 05:15 PM, Chris Hecker wrote: >> Is there a way to disable the error case for chpass to the same >> password? If somebody thinks they've forgotten their password, and I >> send them a change password link and they type the old password in, >> that's fine with me. I don't see a way to specify this in the policy, >> and the mit kadm5 code seems to always do the check, in my cursory >> examination? > > This is a tough call. There is a nonlinearity in the policy code--a > policy -history value of 0 means the same thing as 1--which is most > likely a historical bug. Obviously it would be better if 0 had the > distinct meaning of "no password reuse checking at all". > > However, changing it now could reduce the security of existing > deployments, which we try hard to avoid. In particular, sites which > enforce a minimum and maximum password lifetime, but have neglected to > set the -history value to 1 or more, would start allowing users to > change their password back to the same value again, defeating the point > of the lifetime restrictions. > > We could introduce some kind of opt-in global configuration for the more > consistent meaning; I'm just not sure if it's worth the code and > documentation footprint. > > . > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: disable KADM5_PASS_REUSE error case?
Greg Hudson writes: > On 06/19/2013 05:15 PM, Chris Hecker wrote: >> Is there a way to disable the error case for chpass to the same >> password? If somebody thinks they've forgotten their password, and I >> send them a change password link and they type the old password in, >> that's fine with me. I don't see a way to specify this in the policy, >> and the mit kadm5 code seems to always do the check, in my cursory >> examination? > > This is a tough call. There is a nonlinearity in the policy code--a > policy -history value of 0 means the same thing as 1--which is most > likely a historical bug. Obviously it would be better if 0 had the > distinct meaning of "no password reuse checking at all". I think deleting the policy from the principal (using "modprinc -clearpolicy") will remove all password policy checks, including the unconditional check for repeating the most recent password. I'm not sure whether this is suitable for your situation, because it's best used as a temporary one-shot measure, and has other disadvantages. > However, changing it now could reduce the security of existing > deployments, which we try hard to avoid. In particular, sites which > enforce a minimum and maximum password lifetime, but have neglected to > set the -history value to 1 or more, would start allowing users to > change their password back to the same value again, defeating the point > of the lifetime restrictions. > > We could introduce some kind of opt-in global configuration for the more > consistent meaning; I'm just not sure if it's worth the code and > documentation footprint. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: disable KADM5_PASS_REUSE error case?
On 06/19/2013 05:15 PM, Chris Hecker wrote: > Is there a way to disable the error case for chpass to the same > password? If somebody thinks they've forgotten their password, and I > send them a change password link and they type the old password in, > that's fine with me. I don't see a way to specify this in the policy, > and the mit kadm5 code seems to always do the check, in my cursory > examination? This is a tough call. There is a nonlinearity in the policy code--a policy -history value of 0 means the same thing as 1--which is most likely a historical bug. Obviously it would be better if 0 had the distinct meaning of "no password reuse checking at all". However, changing it now could reduce the security of existing deployments, which we try hard to avoid. In particular, sites which enforce a minimum and maximum password lifetime, but have neglected to set the -history value to 1 or more, would start allowing users to change their password back to the same value again, defeating the point of the lifetime restrictions. We could introduce some kind of opt-in global configuration for the more consistent meaning; I'm just not sure if it's worth the code and documentation footprint. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
disable KADM5_PASS_REUSE error case?
Is there a way to disable the error case for chpass to the same password? If somebody thinks they've forgotten their password, and I send them a change password link and they type the old password in, that's fine with me. I don't see a way to specify this in the policy, and the mit kadm5 code seems to always do the check, in my cursory examination? In my case, I can catch that error and just do nothing (assuming if I'm on LDAP it means it matches the current password, since there's no password history, right?), but it seems like this should be settable in the policy? Chris Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
