It’s no secret. We’re really bad at passwords. Nevertheless, they aren’t going away any time soon.
- Iso Password Standards 2016
- Iso 27001 Password Standards
- Iso Password Crack
- Iso Password Remover
- Iso Password Standards Chart
The system must allow users to select and change their own passwords and include a confirmation procedure to allow for input errors. The system must not display passwords on the screen when being entered. The system must store and transmit passwords in a protected form.
With so many websites and online applications requiring us to create accounts and think up passwords in a hurry, it’s no wonder so many of us struggle to follow the advice of so-called password security experts.
At the same time, the computing power available for password cracking just gets bigger and bigger.
OK, so I started with the bad news, but this cloud does have a silver lining.
It doesn’t need to be as hard as we make it and the government is here to help.
That’s right, the United States National Institute for Standards and Technology (NIST) is formulating new guidelines for password policies to be used in the whole of the US government (the public sector).
Why is this important? Because the policies are sensible and a great template for all of us to use within our own organizations and application development programs.
Anyone interested in the draft specification for Special Publication 800-63-3: Digital Authentication Guidelines can review it as it evolves over on Github or in a more accessible form on NIST’s website.
For a more human approach, security researcher Jim Fenton did a presentation earlier this month at the PasswordsCon event in Las Vegas that sums up the changes nicely.
What’s new ?
What are the major differences between current received wisdom about “secure passwords” and what NIST is now recommending?
Some of the recommendations you can probably guess; others may surprise you.
We’ll start with the things you should do.
Favor the user. To begin with, make your password policies user friendly and put the burden on the verifier when possible.
In other words, we need to stop asking users to do things that aren’t actually improving security.
Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause.
Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.)
Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”
Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!
This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.
We often advise people to use passphrases, so they should be allowed to use all common punctuation characters and any language to improve usability and increase variety.
Check new passwords against a dictionary of known-bad choices. You don’t want to let people use
ChangeMe
, thisisapassword
, yankees
, and so on. More research needs to be done into how to choose and use your “banned list,” but Jim Fenton thinks that 100,000 entries is a good starting point.
The don’ts
Now for all the things you shouldn’t do.
No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not
&%#@_
, and the surname of at least one astronaut.” Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as
pA55w+rd
.No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen.
People set password hints like
rhymes with assword
when you allow hints. (Really! We have some astonishing examples from Adobe’s 2013 password breach.)Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”
No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.
The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.
There’s more…
NIST also provides some other very worthwhile advice.
All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.
You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.
Password hashing enthusiasts are probably wondering, “What about bcrypt and scrypt?” In our own How to article, we listed both of these as possibilities, but wrote, “We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.” NIST followed the same reasoning.
Additionally, and this is a big change: SMS should no longer be used in two-factor authentication (2FA).
There are many problems with the security of SMS delivery, including malware that can redirect text messages; attacks against the mobile phone network (such as the so-called SS7 hack); and mobile phone number portability.
Phone ports, also known as SIM swaps, are where your mobile provider issues you a new SIM card to replace one that’s been lost, damaged, stolen or that is the wrong size for your new phone.
In many countries it is unfortunately far too easy for criminals to convince a mobile phone store to transfer someone’s phone number to a new SIM and therefore hijacking all their text messages.
What next?
This is just the tip of the iceberg, but certainly some of the most important bits.
Password policies need to evolve as we learn more about how people use and abuse them.
Sadly there have been more than enough breaches for us to see the impacts of certain types of policy, such as the evidence shown above from Adobe’s 2013 hack about the danger of password hints.
NIST’s goal is to get us to protect ourselves reliably without unneeded complexity, because complexity works against security.
What are your thoughts on these changes? Will you implement them for your organization? Tell us in the comments.
LEARN MORE ABOUT PASSWORD MYTHS
(Audio player above not working? Download MP3, listen on Soundcloud or access via iTunes.)
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[1] that define requirements for user authentication to government services, including requirements for passwords.
- 1Aspects
- 2Selection process
Aspects[edit]
Typical components of a password policy include:
Password length and formation[edit]
Many policies require a minimum password length. Eight characters is typical but may not be appropriate.[2][3][4] 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:
Iso Password Standards 2016
- 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[edit]
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[edit]
Some policies require users to change passwords periodically, often every 90 or 180 days. The benefit of password expiration, however, is debatable.[5][6] Systems that implement such policies sometimes prevent users from picking a password too close to a previous selection.[7]
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.[clarification needed] 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.[8] 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.[9]
Sanction[edit]
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[citation needed]. Some[who?] consider a convincing explanation of the importance of security to be more effective than threats of sanctions[citation needed].
Selection process[edit]
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[edit]
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[10] 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.[11] 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.'[12]
NIST guidelines[edit]
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:[13]:5.1.1.2
- 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. Online Breach Databases[14], Breached Collections[15]
- 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.
Iso 27001 Password Standards
NIST included a rationale for the new guidelines in its Appendix A.
Enforcing a policy[edit]
The more complex a password policy, the harder it may be to enforce, due to user difficulty in remembering or choosing a suitable password.
Iso Password Crack
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.
Iso Password Remover
See also[edit]
Iso Password Standards Chart
References[edit]
- ^Improving Usability of Password Management with Standardized Password Policies. Retrieved on 2012-10-12.
- ^'Password Complexity Requirements'. The Bug Charmer. September 7, 2012.
- ^'How long should passwords be?'. The Bug Charmer. June 20, 2016.
- ^John D. Sutter (August 20, 2010). 'How to create a 'super password''. CNN. Retrieved August 31, 2016.
- ^'The problems with forcing regular password expiry'. IA Matters. CESG: the Information Security Arm of GCHQ. 15 April 2016. Archived from the original on 17 August 2016. Retrieved 5 Aug 2016.
- ^spaf (April 19, 2006). 'Security Myths and Passwords'. CERIAS.
- ^'Tip: Best Practices for Enforcing Password Policies'. Microsoft. Retrieved 2018-03-01.
- ^Yinqian Zhang; Fabian Monrose; Michael K. Reiter (2010). The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis(PDF). Proceedings of the 17th ACM conference on Computer and communications security. New York, NY, US. pp. 176–186. doi:10.1145/1866307.1866328.
- ^'Choosing Secure Passwords'. BoingBoing. March 2014 – via Schneier on Security.
- ^Where do security polices come from? Proc. Symp. Usable Privacy and Security, 2010
- ^spaf (May 11, 2006). 'Passwords and Myth'. CERIAS.
- ^Rosenbush, Steven; Norton, Steven (May 27, 2015). 'For CISOs, IRS Breach Highlights Tension Between Security and User Convenience'. The Wall Street Journal.
- ^Grassi Paul A (June 2017). 'SP 800-63B-3 – Digital Identity Guidelines, Authentication and Lifecycle Management'. NIST. doi:10.6028/NIST.SP.800-63b.Cite journal requires
|journal=
(help)This article incorporates text from this source, which is in the public domain. - ^Authlogics Password Breach Database
- ^Skullsecurity list of breached password collections
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Password_policy&oldid=918134759'