Password-Handling Guidelines

Transcription

1 Tutorials, A. Allan, R. Witty Research Note 22 December 2003 Best Practices for Managing Passwords: Usage Guidelines Good password-handling rules limit opportunities for attackers to discover passwords. Managing the password life cycle via aging and history procedures also can minimize attackers' windows of opportunity. Core Topic Security and Privacy: Security Management Strategies and Processes Key Issues How will enterprises arm themselves to address increasing information security risk? How will enterprises manage the complexity of authentication and access control in a highly distributed world? Passwords are a ubiquitous authentication mechanism but are effective only as long as they remain secret. However, user behavior and administrative procedures are often slack about this, giving potential attackers many opportunities to easily discover users' passwords by accident or design. Many instances of such discovery over more than 10 years are widely known, yet many enterprises still do not enforce good usage guidelines. Password-Handling Guidelines Users must not disclose passwords to anyone. Period. Not even to system administrators. This rule is the best defense against social-engineering attacks against users. The corollary is that users must not change their passwords to values suggested by someone else. Even if other users have a legitimate need to access a user's PC, such as to install new software, they should have an alternative way to do so, such as by using an administrator account. Allowing exceptions only make users more vulnerable to social-engineering attacks. Users must be wary of accidental disclosure. When entering passwords into a computer system, users should be aware of who might be lurking in the background to ensure that no one can see what is being typed. Although "password blinding" (that is, echoing dummy characters to the screen) provides a technical defense against such "shoulder surfing" attacks, a perceptive attacker may be able to determine the password from looking at the keyboard and the user's hand movements. Users should be encouraged not to worry about appearing to be rude if they ask others nearby to look away when they type their passwords. They should change passwords immediately after using them for remote access from a publicly shared PC (for example, kiosk and Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 Internet cafe) because of the risk of passwords being captured by a key-logging dongle or software. Users should not write down passwords. This is difficult to enforce rigorously, so it is difficult for enterprises to state, "Users must not write down passwords." Pragmatically, you should accept that some users will write down their passwords. However, it is difficult to offer advice to such people without appearing to condone the practice. Nevertheless, these points may be useful to recidivists: Write down only personal clues or cues to the password, rather than the password itself. Do not identify the password as such or identify where the password is used. Do not attach a list of passwords to your PC or anything nearby even under the keyboard, mouse pad or drink coaster. This at least can be enforced, perhaps at a local management level, by periodic visual inspection of desk areas. (An enterprise's security department ordered Post-It notes with the preprinted message, "Please, don't put your password on me.") Administrators must securely communicate passwords to users. If new or reset passwords must be communicated to remote users, they may be written down or printed, but they must be sent under separate cover from the user ID. Administrators should use secure envelopes (this is common for automated teller machine PINs, for example) and users should destroy these promptly post-receipt, preferably using a cross-cut shredder. Administrators also must not send passwords to users via unencrypted . The risks of doing so have been known at least since Clifford Stoll published "The Cuckoo's Egg" in 1990, yet it is still common in many organizations. Devolving password reset authority to line management and administrative support enables passwords to be communicated face to face. However, this is not always possible; on some systems, password management capabilities can't be devolved without giving those users broader scope (such as over users in other organizational units) or functionality (such as other administrative privileges). Third-party password management or user provisioning tools may be useful here. Users should not store passwords unless encrypted or password-protected. This applies to PDAs, cellular phones, Universal Serial Bus-pluggable drives or other portable devices. However, similar to written-down passwords, this rule may be difficult to enforce. It also applies to files on users' PCs. Some client operating systems (for example, Apple Computer's Mac 22 December

3 OS X) and Web browsers (for example, Mozilla) can store various passwords in encrypted form, but with variable levels of security (for example, encryption is only optional in Mozilla). Discrete "password keeper" software is also available, such as Password Safe (see Review such software and publish a schedule of approved client software (if any) in the password management policy (such software may be prohibited by a "locked desktop configuration" policy). Similarly, users should not check the "Remember my password" boxes in client software, such as instant messaging and virtual private networks. Users should not use the same passwords for systems managed by different organizations. Using "internal" passwords on external systems may compromise the enterprise's security if the external system is bound by a less-rigorous password management policy. Indiscriminate reuse of an internal password on the Web may leave the user and hence the enterprise victim to sites that are set up primarily to harvest passwords, or to legitimate sites that send the user unencrypted containing the password, which is vulnerable to harvesting. Although enterprises cannot enforce this rule, they should advise users of the risks and encourage good practices. Special Considerations for Shared Passwords Administrators may need to write down passwords that must be shared, such as for root accounts, "firecall" user accounts, software-only user accounts and others, so that they are available to authorized people when required. The written passwords must be stored under dual control so that no one person has sole access to it. For example: In a safe with two separate locks, with keys for each held by different people. (It could be more than two people, to ensure availability, but any one person must hold only one key.) Partial passwords held by two or more people. If the password is q2w3e4r5t6y7, one person might hold q2w3 y7, another e4r5t6. More complex schemes can allow a partial password to be held by each of n people, but so that <n parts are required to provide a complete password for example, two out of three: q2w3 r5t6, q2 e4r5 y7 and w3e4 t6y7. (As with the keys, the partial passwords could be held by more than two or more than n people.) The common vulnerability with this scenario is that the person who sets the password has sole access from the beginning. An 22 December

4 automated way of generating, setting and securely printing the password may be appropriate, but it must be reliable. Managing the Password Life Cycle: Aging and History Passwords may expire after a given period that is, the password can be used for logon, but the user is forced to choose a new password. The period should be based on the risk to the information that the password is protecting. Ninety days is common, but in more risk-averse industries such as financial services, periods of 21 to 31 days are not unusual. For passwords that protect sensitive information or are used to authenticate privileged roles, such as system administrators or funds transfer processing, a shorter period is desirable. Some financial services companies have enforced a seven-day period for their system administrators. Enterprises looking for a higher level of security should consider the use of stronger authentication mechanisms, such as tokens. Password aging is commonly advocated as a necessary standard, but it is difficult to identify cases where it has defeated an attacker. Unless the expiry period is only a few days, an attacker will have long enough to do mischief. The real benefit to enterprises is to limit the scope for an attack especially that of an ex-employee to use an orphaned or ghost account to access the network where employee termination procedures are inadequate or poorly executed. A better mechanism is to lock/revoke accounts after a period of inactivity, or to use user provisioning tools to lock/revoke or delete accounts across all systems when the human resources system indicates a termination. A problem with aging is that having to frequently change passwords is a major reason why users have difficulty remembering their passwords. This can yield operational and security problems: A high help desk call volume for password resets Users are more likely to write down their passwords In addition, for business-to-consumer Web-based applications, enforcing password aging can inconvenience customers. Reusing passwords should be prohibited for at least six cycles to avoid (accidental) reuse of passwords that users changed because of known or suspected disclosure. If you do choose to enforce password aging, the password history should be longer if the maximum password age is 30 days or less. Say: 22 December

5 12 cycles if 30 days 52 cycles if seven days You may also want to disallow multiple successive password resets in a given period so that users cannot quickly cycle through a series of passwords to come back to the same password each time for example, works4me, app1111e, bana22na, clement1n, dam555on, e66plant, and back to works4me. Password Reset Administrators should follow a clear procedure to verify users who are asking for password resets. This is the best defense against social-engineering attacks against administrators, but only if it is rigorously adhered to. Administrators must resist attempts to get them to shortcut the procedure "because it's urgent." Callback and caller line identification are of limited use because an attacker may well have access to the user's desk and phone (especially for insider attacks), or may have hacked the telephone system. The procedure should embed challengeresponse questions and answers, a technique commonly used in self-service password reset products (see "Best Practices for Managing Passwords: Self-Service Q&A"). Information that the enterprise holds about users (for example, in a human resources management system) must not be used. Devolving password reset authority to line management and administrative support enables the best kind of user verification: face-to-face contact. In addition, passwords set by administrators must expire immediately that is, users must change them on first use. Key Facts: Good password usage guidelines will minimize the likelihood of disclosure to a potential attacker. You should document and enforce password-handling guidelines for users and administrators. Password aging is not an effective security mechanism and is troublesome for users. Password history of at least six cycles will limit the chance reuse of an old password that may have been disclosed or discovered. You should document and enforce password-reset procedures for administrators. 22 December

6 Bottom Line: Many password vulnerabilities emerge or are exacerbated because users and administrators are lax in the way they handle passwords. Properly configure system-level behavior and back it up with effective procedures for password handling. 22 December