Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Password policy
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Aspects== Typical components of a password policy include: ===Password length and formation=== {{see also|Password strength}} Many policies require a minimum password length. Eight characters is typical but may not be appropriate.<ref>{{cite web|url=http://bugcharmer.blogspot.com/2012/09/password-complexity-requirements.html|title=Password Complexity Requirements|publisher=The Bug Charmer|date=September 7, 2012}}</ref><ref>{{cite web|url=http://bugcharmer.blogspot.com/2012/06/how-long-should-passwords-be.html|title=How long should passwords be?|publisher=The Bug Charmer|date=June 20, 2016}}</ref><ref>{{cite web | url=http://www.cnn.com/2010/TECH/innovation/08/20/super.passwords/ | title=How to create a 'super password' | work=CNN | date=August 20, 2010 | accessdate=August 31, 2016 | author=John D. Sutter}}</ref> Longer passwords are almost always more secure, but some systems impose a maximum length for compatibility with [[legacy system]]s. 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 [[Blocklist (computing)|blocklist]] *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 an initial password for the user; but require then to change it to one of their own choosing within a short interval. ===Password block list=== Password block lists are lists of passwords that are always blocked from use. Block lists 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 breach|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.<ref name=WEB> {{cite web |url = https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry |title = The problems with forcing regular password expiry |date = 15 April 2016 |work = IA Matters |publisher = CESG: the Information Security Arm of GCHQ |accessdate = 5 Aug 2016 |url-status = dead |archiveurl = https://web.archive.org/web/20160817223701/https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry |archivedate = 17 August 2016 }} </ref><ref>{{cite web|url=http://www.cerias.purdue.edu/site/blog/post/password-change-myths/|title=Security Myths and Passwords |publisher=CERIAS|date=April 19, 2006 |author=spaf}}</ref> Systems that implement such policies sometimes prevent users from picking a password too close to a previous selection.<ref>{{cite web |url=https://technet.microsoft.com/en-us/library/ff741764.aspx |title=Tip: Best Practices for Enforcing Password Policies |publisher=[[Microsoft]] |access-date=2018-03-01}}</ref> This policy can often backfire. Some users find it hard to devise "[[Password strength|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 [[Cryptographic hash function|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 (See [[Password fatigue]]). 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.{{clarify|date=December 2015}} 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.<ref>{{cite conference | url=http://cs.unc.edu/~fabian/papers/PasswordExpire.pdf | title=The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis | date=2010 | author=Yinqian Zhang|author2=Fabian Monrose|author3=Michael K. Reiter | pages=176β186 | conference=Proceedings of the 17th ACM conference on Computer and communications security | doi=10.1145/1866307.1866328 | location=New York, NY, US}}</ref> 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.<ref>{{cite web|url=https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html|title=Choosing Secure Passwords|via=Schneier on Security|publisher=BoingBoing|date=March 2014}}</ref> ===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 in some jurisdictions.<ref>{{Cite web|url=https://www.eff.org/deeplinks/2016/07/ever-use-someone-elses-password-go-jail-says-ninth-circuit|title=Ever Use Someone Elseβs Password? Go to Jail, says the Ninth Circuit|first=Jamie|last=Williams|date=July 11, 2016|website=Electronic Frontier Foundation}}</ref> Some{{who|date=February 2014}} consider a convincing explanation of the importance of security to be more effective than threats of sanctions{{citation needed|date=February 2014}}.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)