![]() |
>> |
Password Aging Status | Content |
| This document is a draft recommendation. |
OverviewPassword Aging is the concept that a user must periodically change his or her password in order to continue to authenticate to services. If the password is not changed within a specific amount if time, it expires and must be reset.The idea behind password aging is that a password is less likely to be compromised if it is changed regularly, or that the exposure from such a compromise will be reduced, and that a user who stops using a service will have their password automatically expire if they do not otherwise intervene. This can help reduce the exposure to password sniffing and social engineering. Password aging may also be problematic. Users who are required to change their passwords frequently may choose easier to guess passwords since they are also easier to remember. Requiring users to choose more sophisticated passwords may also result in these passwords being written down. Additionally, password aging does not protect a password that is compromised until the password has reached its scheduled expiration time. It seems that most compromises would happen while a password is still valid. A better security focus would be to require the use of secure means of password transmission (SSH, SSL) or validation (Kerberos), and the provision of one time passwords (OPIE) for connections from untrusted terminals. Proper training of users in regards to social engineering techniques (unsolicited telephone calls and emails) is also required. OptionsNevertheless, as some systems require password aging to meet governmental, auditing, or other requirements, it is necessary to remain officially agnostic on the subject. As such, a password aging system meeting the following requirements is proposed:
Three mechanisms for implementing password aging have been proposed. 1. Decentralized Password AgingIt is up to each service requiring password aging to implement it on their own. The service must keep track of when a password was changed (using their own heuristic or via approved queries to the authentication server) and tell its users that a password change is required (via an approved password changing mechanism).This system meets all requirements, but is technically redundant (each service reimplements the infrastructure) and may be difficult to monitor (each infrastructure may differ slightly or significantly). It differs only slightly from letting each service maintain its own passwords, which would not fulfill the first requirement.
2. Decentralized Policy/Centralized EnforcementThe application performing authentication must use an approved method for authentication[1] and indicate the maximum age of a password that is considered acceptable. If the password is too old, the authentication system may return an error suitable to the capabilities of the mechanism ("permission denied" or "password expired"), or the authentication system may prompt the user immediately to change the expired password, thus allowing a successful login to the service.This system meets all requirements. However, a user may be able to login to one service while being rejected from another, making it more difficult for HelpDesk personnel to troubleshoot. (There would be no central repository of password aging policies to examine.) 3. Centralized Password AgingThe user's password expiration time is stored in the central authentication system[2] as part of the password's attributes. When the password expires, all authentication for the user will cease until the password is changed. Whether or not a person is subject to password aging would be determined by information fed by the services requiring this service.This system meets all requirements, assuming a suitable implementation of translating and imposing expirations in accordance with data provided by the requesting services. However, this data feed imposes extra overhead in tracking policies to users and making sure appropriate updates are handled when a new user is introduced to a service or an old user is removed from it. This mechanism differs only slightly from requiring all users to be subject to password aging, which would not fulfill the second requirement. RecommendationOf these three mechanisms, approach #2 is recommended. It places the important control of policies into the hands of the owners of the applications, easing administration of the system. Locally, this approach will also require fewer modifications to implement[3] than approach #3, while allowing fewer redundancies from participating services than approach #1.[1] Locally, via PAM or WIND. [2] Locally, the KDC. [3] Approach #2 will require changes to the krb54 PAM and to WIND. Approach #3 will require a system for receiving policy information, a system for implementing policy information, and changes to WebPasswd to recognize expired passwords and permit their changes. |