PAM: The missing (password) link

Password management used to be fairly easy: most computer users had only few accounts to manage and often used the same password for all logins. Things have changed, though: the number of applications and systems most computer users rely on has increased and security best-practices demand regular password changes. As one can imagine, the number of password reset requests in corporate environments has increased over time. From an observer's point of view, password resets are usually trivial: a user with appropriate administrative privileges (usually an IT administrator or a help desk agent) logs into the corresponding system and issues a command to set the user's account password to a new value. The new password is communicated back to the requesting user, who in turn should login and change the password to a value only known to him/her.

PAM, the Pluggable-Authentication-Modules, are often employed on GNU/Linux systems to deal with all aspects of user authentication and password management - including password resets. One of the most notable PAM modules of the last years is the "pam_keyring" module, this module serves a great purpose: it allows users to conveniently and securely store secondary credentials with their GNU/Linux account. Examples of secondary credentials are Email account credentials, website login credentials and WLAN access credentials. The PAM module allows for secure storage of those credentials in an encrypted file stored in the user's home directory; this encrypted file can only be unlocked with the user's GNU/Linux account password. The PAM module attempts to decrypt this file using the user's login password. This is where the plot thickens: users who forget their GNU/Linux account passwords and thus require a password reset will be able to login to their GNU/Linux desktop again, but won't be able to access the secondary credentials stored in the encrypted file anymore as the old login password is still required to decrypt this file.

The obvious solution is to make the encrypted file decipherable again through other means than the user's account password. While this is what seems to be the most logical approach, there is a major drawback: it's a keyring specific solution. Other PAM constellations exist in which password recovery capabilities might be a necessity, for example: if home directories are stored on encrypted file systems and the PAM module "pam_mount" decrypts and mounts the file system on-the-fly using the user's login password during login. Conducting a password reset in such a situation will lead to a loss of information -- the information stored in the user's home directory. Again, a possible solution would be to provide an independent recovery path for decrypting the encrypted file system; a more generic approach is to provide a centralized mechanism for recovering passwords.

However, recovering passwords is a double edged sword: on one side it serves the practical purposes as stated above, but it also adds the risk of unauthorized use. Which countermeasures are appropriate to address this risk is best decided in the context of deployment: large corporations might for example decide that the to-be-made-recoverable passwords need to be encrypted with multiple PGP keys in order to address the risk of a single person reconstructing user passwords. The proposed PAM module should incorporate an appropriate interface to allow for such a customized handling.

Interestingly, the PAM system already declares an error code for situations requiring recoverable passwords: authtok_recover_err. It's just that no code logic has been programmed to actually use this error code (at least not in the Linux-PAM implementation). I would now like to call out for someone to take up this task and implement the missing logic and an according PAM module. Please contact me to discuss some technical issues and requirements I've already identified if you're interested.

Full Story