Gary Winiger wrote: >>> One question; should pam_krb5 doing PKINIT ever try using the password >>> acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below >>> pam_authtok_get like so: >>> >>> login auth required pam_unix_cred.so.1 >>> login auth sufficient pam_krb5.so.1 pkinit >>> login auth requisite pam_authtok_get.so.1 >>> login auth required pam_dhkeys.so.1 >>> login auth required pam_unix_auth.so.1 >>> ? >>> >>> I was thinking that pam_krb5 could try doing PKINIT preauth with the >>> user's password and if that failed would try PKINIT preauth again, this >>> time prompting for the user's PIN. If that is a bad idea then pam_krb5 >>> doing PKINIT would ignore the user's password and always prompt for the >>> PIN regardless of where it was in the auth stack. >>> > > IMO, it is a site configuration error to put pkinit below > authtok_get. That said, it is possible for applications > to set PAM_AUTHTOK before calling pam_authenticate. >
One use case that Will brought from a conversation w/Nico is a soft token that is encrypted in a user's password. The soft token could be something stored on a USB flash drive for instance. > IMO, you either have an administrative error, or an application > error. I'd say, if PAM_AUTHTOK is set to use it rather than > prompt. If it locks out the card, the admin/application will > be noted as buggy. > I'm in agreement here, if the admin has configured their stack this way then they deserve an accelerated smart card lockout. So with this in mind, I think we are in agreement now that PAM_AUTHTOK should be tried in the pkinit option scenario. -- Shawn.
