Discussion of krb5_get_init_creds_password() behavior was Re:problem with the kinit_prompter in kfw 2.5
jaltman at columbia.edu
Thu Feb 19 12:13:12 EST 2004
The kerberos at mit.edu mailing list is an inappropriate place for this
Please hold this discussion on krbdev at mit.edu OR open a bug report in the
Request Tracker by sending e-mail to krb5-bugs at mit.edu.
John Hascall wrote:
>>Beata A. Pruski wrote:
>>>I must say I don't understand why within krb5_get_init_creds_password,
>>>after the first call to krb5_get_init_creds (with use_master being 0)
>>>returns KRB5KDC_ERR_KEY_EXP, there is still another call made to the
>>>same function with use_master set to 1. Shouldn't there be some sort
>>>of "goto" statement:
>>> if (ret == KRB5KDC_ERR_KEY_EXP) ...
>>Consider the situation in which the user has just changed their password
>>but there are multiple secondary KDCs and the password change has not
>>yet been propagated from the primary KDC. The secondary KDCs will think
>>the password is still expired when in fact it has been changed.
>>Therefore, if the password fails we must attempt to contact the Primary
>>KDC in order to ensure that current password is indeed contacted.
>I still think the logic in krb5_get_init_creds_password()
>where it double calls krb5_get_init_creds() is seriously wrong.
>One problem I previously mentioned was (after the core-dump issue
>I raised is resolved) it will double prompt for password, if the user
>enters an empty password.
>Password ...: <Oh, I didn't mean to do that, I'll just return>
>Password ...: <huh?>
>Another problem is that almost for sure you get 2 strikes against
>the "5 strikes and you are out" code for every wrong attempt
>(since the attempt with use_master = 0 contacted the master).
>Ugly as it is, I think the only way to make this really work
>properly is for krb5_get_init_creds() to return an indication
>as to whether or not the reply it is returning came from the
>master kdc and if so, skip the 2nd call (with use_master = 1).
More information about the krbdev