A password policy is a set of rules designed to enhance computer security by encouraging users to employ strong passwords and use them properly. A password policy is often part of an organization's official regulations and may be taught as part of security awareness training. Either the password policy is merely advisory, or the computer systems force users to comply with it. Some governments have national authentication frameworks that define requirements for user authentication to government services, including requirements for passwords.
Video Password policy
Aspects
Typical components of a password policy include:
Password length and formation
Many policies require a minimum password length. Eight characters is typical but may not be appropriate. Longer passwords are generally more secure, but some systems impose a maximum length for compatibility with legacy systems.
Some policies suggest or impose requirements on what type of password a user can choose, such as:
- the use of both upper-case and lower-case letters (case sensitivity)
- inclusion of one or more numerical digits
- inclusion of special characters, such as @, #, $
- prohibition of words found in a password blacklist
- prohibition of words found in the user's personal information
- prohibition of use of company name or an abbreviation
- prohibition of passwords that match the format of calendar dates, license plate numbers, telephone numbers, or other common numbers
Other systems create the password for the users or let the user select one of a limited number of displayed choices.
Password blacklists
Password blacklists are lists of passwords that are always blocked from use. Blacklists contain passwords constructed of character combinations that otherwise meet company policy, but should no longer be used because they have been deemed insecure for one or more reasons, such as being easily guessed, following a common pattern, or public disclosure from previous data breaches. Common examples are Password1, Qwerty123, or Qaz123wsx.
Password duration
Some policies require users to change passwords periodically, often every 90 or 180 days. The benefit of password expiration, however, is debatable. Systems that implement such policies sometimes prevent users from picking a password too close to a previous selection.
This policy can often backfire. Some users find it hard to devise "good" passwords that are also easy to remember, so if people are required to choose many passwords because they have to change them often, they end up using much weaker passwords; the policy also encourages users to write passwords down. Also, if the policy prevents a user from repeating a recent password, this requires that there is a database in existence of everyone's recent passwords (or their hashes) instead of having the old ones erased from memory. Finally, users may change their password repeatedly within a few minutes, and then change back to the one they really want to use, circumventing the password change policy altogether.
The human aspects of passwords must also be considered. Unlike computers, human users cannot delete one memory and replace it with another. Consequently, frequently changing a memorized password is a strain on the human memory, and most users resort to choosing a password that is relatively easy to guess. Users are often advised to use mnemonic devices to remember complex passwords. However, if the password must be repeatedly changed, mnemonics are useless because the user would not remember which mnemonic to use. Furthermore, the use of mnemonics (leading to passwords such as "2BOrNot2B") makes the password easier to guess.
Administration factors can also be an issue. Users sometimes have older devices that require a password that was used before the password duration expired. In order to manage these older devices, users may have to resort to writing down all old passwords in case they need to log into an older device.
Requiring a very strong password and not requiring it be changed is often better. However, this approach does have a major drawback: if an unauthorized person acquires a password and uses it without being detected, that person may have access for an indefinite period.
It is necessary to weigh these factors: the likelihood of someone guessing a password because it is weak, versus the likelihood of someone managing to steal, or otherwise acquire without guessing, a stronger password.
Bruce Schneier argues that "pretty much anything that can be remembered can be cracked", and recommends a scheme that uses passwords which will not appear in any dictionaries.
Sanction
Password policies may include progressive sanctions beginning with warnings and ending with possible loss of computer privileges or job termination. Where confidentiality is mandated by law, e.g. with classified information, a violation of password policy could be a criminal offense. Some consider a convincing explanation of the importance of security to be more effective than threats of sanctions.
Maps Password policy
Selection process
The level of password strength required depends, among other things, on how easy it is for an attacker to submit multiple guesses. Some systems limit the number of times a user can enter an incorrect password before some delay is imposed or the account is frozen. At the other extreme, some systems make available a specially hashed version of the password, so that anyone can check its validity. When this is done, an attacker can try passwords very rapidly; so much stronger passwords are necessary for reasonable security. (See password cracking and password length equation.) Stricter requirements are also appropriate for accounts with higher privileges, such as root or system administrator accounts.
Usability considerations
Password policies are usually a tradeoff between theoretical security and the practicalities of human behavior. For example:
- Requiring excessively complex passwords and forcing them to be changed frequently can cause users to write passwords down in places that are easy for an intruder to find, such as a Rolodex or post-it note near the computer.
- Users often have dozens of passwords to manage. It may be more realistic to recommend a single password be used for all low security applications, such as reading on-line newspapers and accessing entertainment web sites.
- Similarly, demanding that users never write down their passwords may be unrealistic and lead users to choose weak ones (or cause a lot of inconvenience when users forget their password). An alternative is to suggest keeping written passwords in a secure place, such as a safe or an encrypted master file. The validity of this approach depends on what the most likely threat is deemed to be. While writing down a password may be problematic if potential attackers have access to the secure store, if the threat is primarily remote attackers who do not have access to the store, it can be a very secure method.
- Inclusion of special characters can be a problem if a user has to log onto a computer in a different country. Some special characters may be difficult or impossible to find on keyboards designed for another language.
- Some identity management systems allow self-service password reset, where users can bypass password security by supplying an answer to one or more security questions such as "where were you born?", "what's your favorite movie?", etc. Often the answers to these questions can easily be obtained by social engineering, phishing or simple research.
A 2010 examination of the password policies of 75 different websites concludes that security only partly explains more stringent policies: monopoly providers of a service, such as government sites, have more stringent policies than sites where consumers have choice (e.g. retail sites and banks). The study concludes that sites with more stringent policies "do not have greater security concerns, they are simply better insulated from the consequences from poor usability."
Other approaches are available that are generally considered to be more secure than simple passwords. These include use of a security token or one-time password system, such as S/Key, or multi-factor authentication. However, these systems heighten the tradeoff between security and convenience: according to Shuman Ghosemajumder, these systems all improve security, but come "at the cost of moving the burden to the end user."
NIST Guidelines
In June 2017, the United States National Institute of Standards and Technology (NIST) issued a new revision of their digital authentication guidelines, NIST SP 800-63B-3, stating that:
- Passwords must be at least 8 characters in length if chosen by the subscriber.
- Password verifier systems should permit subscriber-chosen passwords at least 64 characters in length.
- All printing ASCII characters as well as the space character should be acceptable in passwords. Acceptance of Unicode characters is also permitted.
- Verifiers may replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length, but truncation of the password shall not be performed.
- Verifiers should not impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for passwords.
- Verifiers should not require passwords to be changed arbitrarily (e.g., periodically). However, verifiers shall force a change if there is evidence of compromise of the password.
- Verifiers shall not permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant, and verifiers shall not prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing passwords.
- When processing requests to establish or change passwords, verifiers shall compare the prospective passwords against a list that contains values known to be commonly-used, expected, or compromised. The list may include, but is not limited to:
- Passwords obtained from previous breach corpuses [e.g.]
- Dictionary words
- Passwords consisting of repetitive or sequential characters (e.g. 'aaaaaa', '1234abcd')
- Context-specific words, such as the name of the service, the username, and derivatives thereof
- If the chosen password is found in the list, the verifier shall advise the subscriber that they need to select a different password and provide the reason for rejection.
- Verifiers should offer guidance to the subscriber, such as a password-strength meter, to assist the user in choosing a strong password. This is particularly important following the rejection of a password on the above list as it discourages trivial modification of blacklisted (and likely very weak) passwords.
- Verifiers shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber's account.
- Verifiers shall store passwords in a form that is resistant to offline attacks. Passwords shall be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive.
NIST included a rationale for the new guidelines in its Appendix A.
Enforcing a policy
The more complex a password policy, the harder it may be to enforce, due to user difficulty in remembering or choosing a suitable password.
Most companies will require users to familiarize themselves with any password policy, much in the same way a company would require employees to be aware of Health & Safety regulations, or building fire exits, however it is often difficult to ensure that the relevant policies are actually being followed without systems in place that automatically enforce the policy. Many systems, such as Microsoft Windows, that require passwords have built-in methods of enforcing the set policy. This is the only reliable way to ensure that the policy is being followed.
See also
- Random password generator
- Secure error messages in software systems
- Single sign-on
References
Source of article : Wikipedia
0 Comments