On Friday, December 01, 2006 11:15:00 AM -0600 Nicolas Williams <Nicolas.Williams at Sun.COM> wrote:
>> pam_sm_chauthtok >> ---------------- >> >> if PAM_AUTHTOK != NULL >> create hash based on PAM_AUTHTOK with random seed and >> default sequence number >> else >> conversation ask if user wants to set a new hash >> if true >> conversation for hash, sequence number, and seed >> update otp-table >> return PAM_SUCCESS >> else >> return PAM_IGNORE > > I say return an error, not PAM_IGNORE, if the user has an OTP entry but > didn't answer the prompt. I thought so too, at first glance, but now I don't. If you are running passwd(1) or similar, then you don't want the user's decision not to change the OTP credentials to prevent changing other auth tokens controlled by modules later in the stack. If you are some other application changing the password in response to PAM_NEW_AUTHTOK_REQD, then if the user has refused to set a new hash, it is still OK to let them in. This is different from an auth mechanism like Kerberos, where if the auth module returned PAM_NEW_AUTHTOK_REQUIRED, you have no way to validate the user's credentials until they change their password. With OTP, the authentication has already been done, _and_ the last password in the chain has been used. So if they say "no" and you _don't_ let them in, then they don't get another try. But if you do let them in, they can potentially use passwd(1) to reset the OTP chain. -- Jeff
