password policy is a set of rules designed to improve computer security by encouraging users to use strong passwords and use them correctly. Password policies are often part of official organizational rules and can be taught as part of a security awareness training. Password policy is simply an advisory, or a computer system forces users to comply. Some governments have national authentication frameworks that define requirements for user authentication to government services, including requirements for passwords.
Video Password policy
Aspect
Typical components of a password policy include:
Password length and formation
Many policies require a minimum password length. Eight characters are typical but may not be right. Longer passwords are generally safer, but some systems impose a maximum length for compatibility with legacy systems.
Some policies suggest or enforce requirements about what type of password a user can choose, such as:
- uppercase and lowercase letters (letter sensitivity)
- one-digit or more numerical inclusion
- special character inclusion, such as @, #, $
- banning words found in password blacklist
- banning words found in user's personal information
- ban of using company name or abbreviation
- a password prohibition matching the calendar date format, license plate number, phone number, or other common number
Another system creates a password for the user or lets the user select one of the number of options displayed.
Password blacklist
A password blacklist is a list of passwords that are always blocked from being used. Blacklists contain passwords made of combinations of characters that otherwise meet company policies, but may not be used anymore because they are considered unsafe due to one or more reasons, such as predictability, following general patterns, or public disclosure of previous data breaches. Common examples are Password1, Qwerty123, or Qaz123wsx.
Password duration
Some policies require users to change their password periodically, often every 90 or 180 days. The benefits of password expiration, however, are debatable. Systems that implement such policies sometimes prevent users from choosing passwords too close to their previous choices.
This policy can often backfire. Some users find it difficult to construct a good "good" password that is also easy to remember, so if people are asked to choose multiple passwords because they have to change them often, they end up using a much weaker password; the policy also encourages users to write passwords. Additionally, if the policy prevents users from repeating their passwords recently, this requires a database in the presence of their recent password (or hash) rather than deleting the old one from memory. Finally, users can change their passwords over and over in a few minutes, and then change back the password they really want to use, avoiding a password change policy altogether.
The human aspect of the password should also be considered. Unlike computers, human users can not delete one memory and replace it with another. As a result, often changing a memorized password is a strain on human memory, and most users choose a password that is relatively easy to guess. Users are often advised to use mnemonic devices to remember complicated passwords. However, if the password has to be repeatedly changed, mnemonics are useless because the user will not remember which mnemonic will be used. Furthermore, the use of mnemonics (which leads to passwords like "2BOrNot2B") makes the password more predictable.
Administrative factors can also be a problem. Users sometimes have older devices that require passwords to use before the duration of the password expires. To manage these older devices, users may have to write down all old passwords if they have to sign in to older devices.
Needing a very strong password and not necessarily changing it is often better. However, this approach does have a major drawback: if an unauthorized person obtains a password and uses it undetected, that person may have access to unlimited time.
You need to consider these factors: the possibility of someone guessing the password because of weakness, versus the possibility of someone trying to steal, or otherwise acquiring without a guess, a stronger password.
Bruce Schneier argues that "enough things to remember can be solved", and recommend schemes that use passwords that will not appear in any dictionary.
Sanctions
Password policies may include progressive sanctions beginning with warnings and ending with the possibility of losing computer rights or termination of work. Where confidentiality is mandated by law, e.g. with confidential information, a violation of the password policy can be a crime. Some people consider a convincing explanation of the importance of security being more effective than the threat of sanctions.
Maps Password policy
Selection process
The required degree of password strength depends, inter alia, on how easily an attacker sends a few guesses. Some systems limit the number of times a user can enter an incorrect password before some delay is enforced or account is frozen. At the other extreme, some systems provide a special version of a hashed password, so that anyone can check its validity. When this is done, an attacker can try passwords very quickly; so many stronger passwords are required for reasonable security. (See password equations for cracking and password length.) Stricter requirements are also appropriate for accounts with higher privileges, such as system administrator or root account.
Usability Considerations
Password policy is usually a tradeoff between the theoretical security and the practicality of human behavior. As an example:
- Needing a password that is too complicated and forcing them to be changed frequently can cause users to write passwords in places easily found by intruders, such as Rolodex or paste near the computer.
- Users often have dozens of passwords to manage. It might be more realistic to recommend a single password used for all low-security applications, such as reading online newspapers and accessing entertainment websites.
- Similarly, demanding that users never write their passwords may be unrealistic and direct users to choose weak ones (or cause lots of inconvenience when users forget their password). Another alternative is to suggest keeping the passwords written in a safe place, such as a secure or encrypted master file. The validity of this approach depends on what is considered the most likely threat. While writing a password may be problematic if potential attackers have access to a secure store, if the threat is mainly a remote attacker who does not have access to the store, it can be a very safe method.
- Special character insertion can be an issue if the user has to sign in to a computer in another country. Some special characters may be difficult or impossible to find on keyboards designed for other languages.
- Some identity management systems allow self-service password resets, where users can bypass password security by providing answers to one or more security questions like "where are you born?", "what is your favorite movie?", etc. Often the answers to these questions can be easily obtained by social engineering, phishing or simple research.
A 2010 examination of the password policy of 75 different websites concludes that security only partially explains stricter policies: monopolist service providers of a service, such as government sites, have more restrictive policies than sites where consumers have choices (eg retail sites and banks ). The study concludes that sites with more stringent policies "have no greater security concerns, they are only better isolated from the consequences of poor usability."
Other approaches are available that are generally considered more secure than simple passwords. This includes the use of a security token or a one-time password system, such as S/Key, or multi-factor authentication. However, this system increases the tradeoff between security and convenience: according to Shuman Ghosemajumder, all these systems improve security, but come "at the expense of moving the load to the end user."
NIST guidelines
In June 2017, the National Institute of Standards and Technology of the United States (NIST) issued a new revision of their digital authentication guidance, NIST SP 800-63B-3, which states that:
- The password must have at least 8 characters if selected by the customer.
- The password verification system must allow the password the customer chooses for at least 64 characters in length.
- All ASCII printed characters and space characters must are accepted in the password. Unicode character acceptance is also allowed.
- The testers can override multiple consecutive spaced characters with one space character before verification, as long as the result is at least 8 characters long, but the code deduction should not be
- The testers must not enforce other composition rules (for example, require a mix of various character types or for successive characters to be banned) for a password.
- The testers should not require that the password be arbitrarily changed (for example, periodically). However, the verifier must
force changes if there is evidence of password compromise. - The Testers will not allow customers to keep "instructions" accessible to unauthorized plaintiffs, and the meter will not require customers to use certain types of information (for example, "What is your first pet's name?") When choosing a password.
- When processing a request to create or change a password, the verifier must compare the prospective password with a list that contains commonly used, expected, or compromised values. The may list includes, but is not limited to:
- Passwords obtained from previous violation corpus [e.g.]
- Words of the dictionary
- Passwords that consist of repetitive or sequential characters (eg 'aaaaaa', '1234abcd')
- Context-specific words, such as service names, usernames, and derivatives
- If the selected password is found in the list, the verifier must notify customers that they need to choose a different password and provide a reason for the decline.
- The testers must offer customer guidance, such as password strength meter, to assist users in choosing strong passwords. It is very important to follow the password decline in the list above because it is not recommended to modify blacklisted passwords (and possibly very weak).
- The testers must implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made to a customer's account.
- The verifier must store the password in a form that is resistant to offline attacks. The password must be salted and ished using the corresponding one-way key derivation function. The main derivation function takes the password, salt, and cost factors as inputs then generates a password hash. Their goal is to make every trial guess the password by an attacker who has been getting expensive password hash files and therefore the cost of a guessing attack is high or expensive.
NIST includes reasons for the new guidelines in Appendix A.
Enforce policies
The more complex the password policy, the harder it is to enforce it, because of the user's difficulty in remembering or choosing the appropriate password.
Most companies will require users to familiarize themselves with the password policy, just as companies require employees to be aware of Health & amp; Safety rules, or building fire exits, but it is often difficult to ensure that the relevant policies are actually followed without a system in place that automatically enforces the policy. Many systems, such as Microsoft Windows, that require a password have a default method to enforce a defined policy. This is the only reliable way to ensure that the policy is followed.
See also
- Random password generator
- A secure error message in the software system
- Single sign-on
References
Source of the article : Wikipedia
0 Comments