> I am not familiar with this "pam_secure_connection" magic of which > you speak. That sounds like an impossible problem; pretty much > anything you think is a "secure" connection could simply be to an > intermediary with an insecure connection out the other side. >
Indeed, but permitting for this stacking gives an admin at least provide some level of control; it's possible to at least check the last hop, and thus prevent exposure on some level. (Or one could write a module that checks for a specific terminal, one that is known to be connected directly or via a secured link and is in a secure location, and deny entering passwords from any other connection/location) > other password ... pam_otp.so.1 > other password ... pam_secure_connection.so.1 > other password ... pam_authtok_get.so.1 > other password ... pam_authtok_otp_check.so.1 > other password ... pam_otp.so.1 (...) > Aside from that, given the specialized nature of the new seed > information, it's not clear to me that it should ever be stored in > PAM_AUTHTOK. It certainly isn't the password that other modules > will be expecting. pam_otp would never store anything in PAM_AUTHTOK: If PAM_AUTHTOK isn't set (in the example this happens the first time pam_otp is called) we'll ask the user if he wants to set a new authentication token by providing hash+seq+seed. If the user does so we update the otp-table and the password/token update routine stops (so the first pam_otp.so.1 should be "binding"). If the user declines to enter hash+seq+seed we return PAM_IGNORE (to allow the stacking to work). The pam_authtok_get module prompts the user for a passphrase/password and sets PAM_AUTHTOK. So, when pam_otp is called the second time PAM_AUTHTOK is set and we'll use it to generate a new hash (with random seed and default sequence number) and store that in the otp- table. Bart
