Editing Password (section)

==Factors in the security of a password system==
{{See also|Password strength|Computer security}}
The security of a password-protected system depends on several factors. The overall system must be designed for sound security, with protection against [[computer virus]]es, [[man-in-the-middle attack]]s and the like. Physical security issues are also a concern, from deterring [[shoulder surfing (computer security)|shoulder surfing]] to more sophisticated physical threats such as video cameras and keyboard sniffers. Passwords should be chosen so that they are hard for an attacker to guess and hard for an attacker to discover using any of the available automatic attack schemes.<ref name=":1" />

Nowadays, it is a common practice for computer systems to hide passwords as they are typed. The purpose of this measure is to prevent bystanders from reading the password; however, some argue that this practice may lead to mistakes and stress, encouraging users to choose weak passwords. As an alternative, users should have the option to show or hide passwords as they type them.<ref name=":1">[http://www.lyquix.com/blog/92-do-we-need-to-hide-passwords Lyquix Blog: Do We Need to Hide Passwords?] {{webarchive|url=https://web.archive.org/web/20120425114556/http://www.lyquix.com/blog/92-do-we-need-to-hide-passwords |date=25 April 2012 }}. Lyquix.com. Retrieved on 20 May 2012.</ref>

Effective access control provisions may force extreme measures on criminals seeking to acquire a password or biometric token.<ref>Jonathan Kent, [http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm Malaysia car thieves steal finger] {{webarchive|url=https://web.archive.org/web/20101120203534/http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm |date=20 November 2010 }}. BBC (31 March 2005)</ref> Less extreme measures include [[extortion]], [[rubber hose cryptanalysis]], and [[side channel attack]].

Some specific password management issues that must be considered when thinking about, choosing, and handling, a password follow.

===Rate at which an attacker can try guessed passwords===
The rate at which an attacker can submit guessed passwords to the system is a key factor in determining system security. Some systems impose a time-out of several seconds after a small number (e.g., three) of failed password entry attempts, also known as throttling.<ref name="NIST-SP-800-63-3" /> {{rp|63B Sec 5.2.2}} In the absence of other vulnerabilities, such systems can be effectively secure with relatively simple passwords if they have been well chosen and are not easily guessed.<ref>Stuart Brown {{cite web |url=http://www.modernlifeisrubbish.co.uk/top-10-most-common-passwords.asp |title=Top ten passwords used in the United Kingdom |access-date=14 August 2007 |url-status=dead |archive-url=https://web.archive.org/web/20061108094949/http://www.modernlifeisrubbish.co.uk/top-10-most-common-passwords.asp |archive-date=8 November 2006 }}. Modernlifeisrubbish.co.uk (26 May 2006). Retrieved on 2012-05-20.</ref>

Many systems store a [[Cryptographic hash function|cryptographic hash]] of the password. If an attacker gets access to the file of hashed passwords guessing can be done offline, rapidly testing candidate passwords against the true password's hash value. In the example of a web-server, an online attacker can guess only at the rate at which the server will respond, while an off-line attacker (who gains access to the file) can guess at a rate limited only by the hardware on which the attack is running and the strength of the algorithm used to create the hash.

Passwords that are used to generate cryptographic keys (e.g., for [[disk encryption]] or [[Wi-Fi]] security) can also be subjected to high rate guessing, known as [[password cracking]]. Lists of common passwords are widely available and can make password attacks efficient. Security in such situations depends on using passwords or passphrases of adequate complexity, making such an attack computationally infeasible for the attacker. Some systems, such as [[Pretty Good Privacy|PGP]] and [[Wi-Fi Protected Access|Wi-Fi WPA]], apply a computation-intensive hash to the password to slow such attacks, in a technique known as [[key stretching]].

===Limits on the number of password guesses===
An alternative to limiting the rate at which an attacker can make guesses on a password is to limit the total number of guesses that can be made. The password can be disabled, requiring a reset, after a small number of consecutive bad guesses (say 5); and the user may be required to change the password after a larger cumulative number of bad guesses (say 30), to prevent an attacker from making an arbitrarily large number of bad guesses by interspersing them between good guesses made by the legitimate password owner.<ref>{{cite patent |country=US |number=8046827 |status=patent}}</ref> Attackers may conversely use knowledge of this mitigation to implement a [[denial-of-service attack|denial of service attack]] against the user by intentionally locking the user out of their own device; this denial of service may open other avenues for the attacker to manipulate the situation to their advantage via [[Social engineering (security)|social engineering]].

===Form of stored passwords===
Some computer systems store user passwords as [[plaintext]], against which to compare user logon attempts. If an attacker gains access to such an internal password store, all passwords—and so all user accounts—will be compromised. If some users employ the same password for accounts on different systems, those will be compromised as well.

More secure systems store each password in a cryptographically protected form, so access to the actual password will still be difficult for a snooper who gains internal access to the system, while validation of user access attempts remains possible. The most secure do not store passwords at all, but a one-way derivation, such as a [[polynomial]], [[Modulo operation|modulus]], or an advanced [[Cryptographic hash function|hash function]].<ref name="SS1">{{cite web| last=Lundin|first=Leigh |title= PINs and Passwords, Part 2 | url=http://www.sleuthsayers.org/2013/08/pins-and-passwords-part-2.html |work=Passwords| publisher=SleuthSayers| location=Orlando| date=11 August 2013}}</ref> [[Roger Needham]] invented the now-common approach of storing only a "hashed" form of the plaintext password.<ref>Wilkes, M. V. Time-Sharing Computer Systems. American Elsevier, New York, (1968).</ref><ref name="guardian">{{cite news|last=Schofield|first=Jack|title=Roger Needham|work=The Guardian|date=10 March 2003|url=https://www.theguardian.com/news/2003/mar/10/guardianobituaries.microsoft}}</ref> When a user types in a password on such a system, the password handling software runs through a cryptographic hash algorithm, and if the hash value generated from the user's entry matches the hash stored in the password database, the user is permitted access. The hash value is created by applying a cryptographic hash function to a string consisting of the submitted password and, in multiple implementations, another value known as a [[salt (cryptography)|salt]]. A salt prevents attackers from easily building a list of hash values for common passwords and prevents password cracking efforts from scaling across all users.<ref>[http://bugcharmer.blogspot.com/2012/06/passwords-matter.html The Bug Charmer: Passwords Matter] {{webarchive|url=https://web.archive.org/web/20131102172331/http://bugcharmer.blogspot.com/2012/06/passwords-matter.html |date=2 November 2013 }}. Bugcharmer.blogspot.com (20 June 2012). Retrieved on 2013-07-30.</ref> [[MD5]] and [[SHA1]] are frequently used cryptographic hash functions, but they are not recommended for password hashing unless they are used as part of a larger construction such as in [[PBKDF2]].<ref name="bugcharmer.blogspot.com">Alexander, Steven. (20 June 2012) [http://bugcharmer.blogspot.com/2012/06/how-long-should-passwords-be.html The Bug Charmer: How long should passwords be?] {{webarchive|url=https://web.archive.org/web/20120920143554/http://bugcharmer.blogspot.com/2012/06/how-long-should-passwords-be.html |date=20 September 2012 }}. Bugcharmer.blogspot.com. Retrieved on 2013-07-30.</ref>

The stored data—sometimes called the "password verifier" or the "password hash"—is often stored in Modular Crypt Format or RFC 2307 hash format, sometimes in the [[/etc/passwd]] file or the [[/etc/shadow]] file.<ref>
[http://pythonhosted.org/passlib/lib/passlib.hash.html "passlib.hash - Password Hashing Schemes"] {{webarchive|url=https://web.archive.org/web/20130721042150/http://pythonhosted.org/passlib/lib/passlib.hash.html |date=21 July 2013 }}.
</ref>

The main storage methods for passwords are plain text, hashed, hashed and salted, and reversibly encrypted.<ref name="An Administrator's Guide to Internet Password Research">Florencio et al., [http://research.microsoft.com/pubs/227130/WhatsaSysadminToDo.pdf An Administrator's Guide to Internet Password Research] {{webarchive|url=https://web.archive.org/web/20150214015800/http://research.microsoft.com/pubs/227130/WhatsaSysadminToDo.pdf |date=14 February 2015 }}. (pdf) Retrieved on 14 March 2015.</ref> If an attacker gains access to the password file, then if it is stored as plain text, no cracking is necessary. If it is hashed but not salted then it is vulnerable to [[rainbow table]] attacks (which are more efficient than cracking). If it is reversibly encrypted then if the attacker gets the decryption key along with the file no cracking is necessary, while if he fails to get the key cracking is not possible. Thus, of the common storage formats for passwords only when passwords have been salted and hashed is cracking both necessary and possible.<ref name="An Administrator's Guide to Internet Password Research"/>

If a cryptographic hash function is well designed, it is computationally infeasible to reverse the function to recover a [[plaintext]] password. An attacker can, however, use widely available tools to attempt to guess the passwords. These tools work by hashing possible passwords and comparing the result of each guess to the actual password hashes. If the attacker finds a match, they know that their guess is the actual password for the associated user. Password cracking tools can operate by brute force (i.e. trying every possible combination of characters) or by hashing every word from a list; large lists of possible passwords in multiple languages are widely available on the Internet.<ref name="SS1" /> The existence of [[password cracking]] tools allows attackers to easily recover poorly chosen passwords. In particular, attackers can quickly recover passwords that are short, dictionary words, simple variations on dictionary words, or that use easily guessable patterns.<ref>[http://blog.thireus.com/cracking-story-how-i-cracked-over-122-million-sha1-and-md5-hashed-passwords Cracking Story – How I Cracked Over 122 Million SHA1 and MD5 Hashed Passwords « Thireus' Bl0g] {{webarchive|url=https://web.archive.org/web/20120830223146/http://blog.thireus.com/cracking-story-how-i-cracked-over-122-million-sha1-and-md5-hashed-passwords |date=30 August 2012 }}. Blog.thireus.com (29 August 2012). Retrieved on 2013-07-30.</ref>
A modified version of the [[Data Encryption Standard|DES]] algorithm was used as the basis for the password hashing algorithm in early [[Unix]] systems.<ref name="cm.bell-labs.com">{{cite journal |url=http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps |archive-url=https://web.archive.org/web/20030322053727/http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps |url-status=dead |archive-date=22 March 2003 |title=Password Security: A Case History |author1=Morris, Robert |author2=Thompson, Ken |name-list-style=amp |journal=Communications of the ACM |volume=22 |issue=11 |year=1979 |pages=594–597 |doi=10.1145/359168.359172 |citeseerx=10.1.1.135.2097 |s2cid=207656012 }}</ref> The [[crypt (Unix)|crypt]] algorithm used a 12-bit salt value so that each user's hash was unique and iterated the DES algorithm 25 times in order to make the hash function slower, both measures intended to frustrate automated guessing attacks.<ref name="cm.bell-labs.com"/> The user's password was used as a key to encrypt a fixed value. More recent Unix or Unix-like systems (e.g., [[Linux]] or the various [[BSD]] systems) use more secure password hashing algorithms such as [[PBKDF2]], [[bcrypt]], and [[scrypt]], which have large salts and an adjustable cost or number of iterations.<ref>[http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf Password Protection for Modern Operating Systems] {{webarchive|url=https://web.archive.org/web/20160311102423/http://usenix.org/publications/login/2004-06/pdfs/alexander.pdf |date=11 March 2016 }} (pdf). Usenix.org. Retrieved on 20 May 2012.</ref>
A poorly designed hash function can make attacks feasible even if a strong password is chosen. [[LM hash]] is a widely deployed and insecure example.<ref>[http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656 How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases] {{webarchive|url=https://web.archive.org/web/20060509045622/http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656 |date=9 May 2006 }}. support.microsoft.com (3 December 2007). Retrieved on 2012-05-20.</ref>

===Methods of verifying a password over a network===

====Simple transmission of the password====

Passwords are vulnerable to interception (i.e., "snooping") while being transmitted to the authenticating machine or person. If the password is carried as electrical signals on unsecured physical wiring between the user access point and the central system controlling the password database, it is subject to snooping by [[Telephone tapping|wiretapping]] methods. If it is carried as packeted data over the Internet, anyone able to watch the [[Network packet|packets]] containing the logon information can snoop with a low probability of detection.

Email is sometimes used to distribute passwords but this is generally an insecure method. Since most email is sent as [[plaintext]], a message containing a password is readable without effort during transport by any eavesdropper. Further, the message will be stored as [[plaintext]] on at least two computers: the sender's and the recipient's. If it passes through intermediate systems during its travels, it will probably be stored on there as well, at least for some time, and may be copied to [[backup]], [[cache (computing)|cache]] or history files on any of these systems.

Using client-side encryption will only protect transmission from the mail handling system server to the client machine. Previous or subsequent relays of the email will not be protected and the email will probably be stored on multiple computers, certainly on the originating and receiving computers, most often in clear text.

====Transmission through encrypted channels====
{{See also|Cryptography}}
The risk of interception of passwords sent over the Internet can be reduced by, among other approaches, using [[cryptography|cryptographic]] protection. The most widely used is the [[Transport Layer Security]] (TLS, previously called [[Secure Sockets Layer|SSL]]) feature built into most current Internet [[Web browser|browsers]]. Most browsers alert the user of a TLS/SSL-protected exchange with a server by displaying a closed lock icon, or some other sign, when TLS is in use. There are several other techniques in use.

====Hash-based challenge–response methods====

There is a conflict between stored hashed-passwords and hash-based [[challenge–response authentication]]; the latter requires a client to prove to a server that they know what the [[shared secret]] (i.e., password) is, and to do this, the server must be able to obtain the shared secret from its stored form. On a number of systems (including [[Unix]]-type systems) doing remote authentication, the shared secret usually becomes the hashed form and has the serious limitation of exposing passwords to offline guessing attacks. In addition, when the hash is used as a shared secret, an attacker does not need the original password to authenticate remotely; they only need the hash.

====Zero-knowledge password proofs====

Rather than transmitting a password, or transmitting the hash of the password, [[password-authenticated key agreement]] systems can perform a [[zero-knowledge password proof]], which proves knowledge of the password without exposing it.

Moving a step further, augmented systems for [[password-authenticated key agreement]] (e.g., [[Authentication and key agreement via Memorable Passwords|AMP]], [[SPEKE|B-SPEKE]], [[PAK-Z]], [[Secure remote password protocol|SRP-6]]) avoid both the conflict and limitation of hash-based methods. An augmented system allows a client to prove knowledge of the password to a server, where the server knows only a (not exactly) hashed password, and where the un-hashed password is required to gain access.

===Procedures for changing passwords===

{{Main|Self-service password reset}}

Usually, a system must provide a way to change a password, either because a user believes the current password has been (or might have been) compromised, or as a precautionary measure. If a new password is passed to the system in unencrypted form, security can be lost (e.g., via [[Telephone tapping|wiretapping]]) before the new password can even be installed in the password [[database]] and if the new password is given to a compromised employee, little is gained. Some websites include the user-selected password in an [[Plain text|unencrypted]] confirmation e-mail message, with the obvious increased vulnerability.

[[Identity management]] systems are increasingly used to automate the issuance of replacements for lost passwords, a feature called [[self-service password reset]]. The user's identity is verified by asking questions and comparing the answers to ones previously stored (i.e., when the account was opened).

Some password reset questions ask for personal information that could be found on social media, such as mother's maiden name. As a result, some security experts recommend either making up one's own questions or giving false answers.<ref>{{cite web |url=http://www.techlicious.com/tip/why-you-should-lie-when-setting-up-password-security-questions/ |title=Why You Should Lie When Setting Up Password Security Questions |publisher=Techlicious |date=8 March 2013 |access-date=16 October 2013 |url-status=live |archive-url=https://web.archive.org/web/20131023045034/http://www.techlicious.com/tip/why-you-should-lie-when-setting-up-password-security-questions/ |archive-date=23 October 2013 }}</ref>

===Password longevity===

"Password aging" is a feature of some operating systems which forces users to change passwords frequently (e.g., quarterly, monthly or even more often). Such policies usually provoke user protest and foot-dragging at best and hostility at worst.<ref>{{Cite conference |last=Shay |first=R. |last2=Komanduri |first2=S. |last3=Kelley |first3=P. G. |last4=Leon |first4=P. G. |last5=Mazurek |first5=M. L. |last6=Bauer |first6=L. |last7=Cranor |first7=L. F. |title=Encountering stronger password requirements: user attitudes and behaviors |book-title=Proceedings of the Sixth Symposium on Usable Privacy and Security |pages=1–20 |year=2010 |url=https://dl.acm.org/doi/10.1145/1837110.1837113 |access-date=April 30, 2025}}</ref> There is often an increase in the number of people who note down the password and leave it where it can easily be found, as well as help desk calls to reset a forgotten password. Users may use simpler passwords or develop variation patterns on a consistent theme to keep their passwords memorable.<ref name="Joseph-Steinberg-Forbes" /> Because of these issues, there is some debate as to whether password aging is effective.<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 |access-date = 5 August 2016 |url-status = dead |archive-url = https://web.archive.org/web/20160817223701/https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry |archive-date = 17 August 2016}}</ref> Changing a password will not prevent abuse in most cases, since the abuse would often be immediately noticeable. However, if someone may have had access to the password through some means, such as sharing a computer or breaching a different site, changing the password limits the window for abuse.<ref>[http://www.schneier.com/blog/archives/2010/11/changing_passwo.html Schneier on Security discussion on changing passwords] {{webarchive|url=https://web.archive.org/web/20101230115557/http://www.schneier.com/blog/archives/2010/11/changing_passwo.html |date=30 December 2010 }}. Schneier.com. Retrieved on 20 May 2012.</ref>

===Number of users per password===

Allotting separate passwords to each user of a system is preferable to having a single password shared by legitimate users of the system, certainly from a security viewpoint. This is partly because users are more willing to tell another person (who may not be authorized) a shared password than one exclusively for their use. Single passwords are also much less convenient to change because multiple people need to be told at the same time, and they make removal of a particular user's access more difficult, as for instance on graduation or resignation. Separate logins are also often used for accountability, for example to know who changed a piece of data.

===Password security architecture===

Common techniques used to improve the security of computer systems protected by a password include:
* Not displaying the password on the display screen as it is being entered or obscuring it as it is typed by using asterisks (*) or bullets (•).
* Allowing passwords of adequate length. (Some [[legacy system|legacy]] operating systems, including early versions{{Which|date=September 2010}} of Unix and Windows, limited passwords to an 8 character maximum,<ref>Seltzer, Larry. (9 February 2010) [https://www.pcmag.com/article2/0,2817,2358985,00.asp "American Express: Strong Credit, Weak Passwords"] {{webarchive|url=https://web.archive.org/web/20170712160714/https://www.pcmag.com/article2/0,2817,2358985,00.asp |date=12 July 2017 }}. Pcmag.com. Retrieved on 2012-05-20.</ref><ref name="password_myths">
[https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments "Ten Windows Password Myths"] : "NT dialog boxes ... limited passwords to a maximum of 14 characters"
</ref><ref>[http://jira.codehaus.org/browse/REDBACK-87 "You must provide a password between 1 and 8 characters in length"]. Jira.codehaus.org. Retrieved on 20 May 2012. {{webarchive |url=https://web.archive.org/web/20150521153629/http://jira.codehaus.org/browse/REDBACK-87 |date=21 May 2015 }}</ref> reducing security.)
* Requiring users to re-enter their password after a period of inactivity (a semi log-off policy).
* Enforcing a [[password policy]] to increase [[password strength]] and security.
** Assigning randomly chosen passwords.
** Requiring minimum [[Password length parameter|password lengths]].<ref name="bugcharmer.blogspot.com"/>
** Some systems require characters from various character classes in a password—for example, "must have at least one uppercase and at least one lowercase letter". However, all-lowercase passwords are more secure per keystroke than mixed capitalization passwords.<ref>[http://world.std.com/~reinhold/dicewarefaq.html#capitalize "To Capitalize or Not to Capitalize?"] {{webarchive|url=https://web.archive.org/web/20090217200722/http://world.std.com/~reinhold/dicewarefaq.html |date=17 February 2009 }}. World.std.com. Retrieved on 20 May 2012.</ref>
** Employ a [[Blacklist (computing)#Usernames and passwords|password blacklist]] to block the use of weak, easily guessed passwords
** Providing an alternative to keyboard entry (e.g., spoken passwords, or [[biometrics|biometric]] identifiers).
** Requiring more than one authentication system, such as two-factor authentication (something a user has and something the user knows).
* Using encrypted tunnels or [[password-authenticated key agreement]] to prevent access to transmitted passwords via network attacks
* Limiting the number of allowed failures within a given time period (to prevent repeated password guessing). After the limit is reached, further attempts will fail (including correct password attempts) until the beginning of the next time period. However, this is vulnerable to a form of [[denial-of-service attack|denial of service attack]].
* Introducing a delay between password submission attempts to slow down automated password guessing programs.

Some of the more stringent policy enforcement measures can pose a risk of alienating users, possibly decreasing security as a result.

=== Password reuse ===

It is common practice amongst computer users to reuse the same password on multiple sites. This presents a substantial security risk, because an [[Hacker (computer security)|attacker]] needs to only compromise a single site in order to gain access to other sites the victim uses. This problem is exacerbated by also reusing [[User (computing)|usernames]], and by websites requiring email logins, as it makes it easier for an attacker to track a single user across multiple sites. Password reuse can be avoided or minimized by using [[Mnemonic|mnemonic techniques]], [[#Writing down passwords on paper|writing passwords down on paper]], or using a [[password manager]].<ref name="Keir-PCWorld-2011">{{cite web | url=http://www.pcworld.com/article/219303/password_use_very_common_research_shows.html | title=Password Reuse Is All Too Common, Research Shows | work=[[PC World]] | date=10 February 2011 | access-date=10 August 2014 | author=Thomas, Keir | url-status=live | archive-url=https://web.archive.org/web/20140812204649/http://www.pcworld.com/article/219303/password_use_very_common_research_shows.html | archive-date=12 August 2014 }}</ref>

It has been argued by Redmond researchers [[Dinei Florencio]] and Cormac Herley, together with Paul C. van Oorschot of Carleton University, Canada, that password reuse is inevitable, and that users should reuse passwords for low-security websites (which contain little personal data and no financial information, for example) and instead focus their efforts on remembering long, complex passwords for a few important accounts, such as bank accounts.<ref name="Darren-Microsoft-Register">{{cite web | url=https://www.theregister.co.uk/2014/07/16/redmond_says_password_reuse_is_more_than_okay_its_necessary/ | title=Microsoft: You NEED bad passwords and should re-use them a lot | work=[[The Register]] | date=16 July 2014 | access-date=10 August 2014 | author=Pauli, Darren | url-status=live | archive-url=https://web.archive.org/web/20140812210549/http://www.theregister.co.uk/2014/07/16/redmond_says_password_reuse_is_more_than_okay_its_necessary/ | archive-date=12 August 2014 }}</ref> Similar arguments were made by [[Forbes]] in not change passwords as often as some "experts" advise, due to the same limitations in human memory.<ref name="Joseph-Steinberg-Forbes">{{cite news | url=https://www.forbes.com/sites/josephsteinberg/2014/11/12/why-you-should-ignore-everything-you-have-been-told-about-choosing-passwords/ | title=Forbes: Why You Should Ignore Everything You Have Been Told About Choosing Passwords | work=[[Forbes]] | date=12 November 2014 | access-date=12 November 2014 | author=Joseph Steinberg | url-status=live | archive-url=https://web.archive.org/web/20141112170839/http://www.forbes.com/sites/josephsteinberg/2014/11/12/why-you-should-ignore-everything-you-have-been-told-about-choosing-passwords/ | archive-date=12 November 2014 }}</ref>

=== Writing down passwords on paper ===

Historically, multiple security experts asked people to memorize their passwords: "Never write down a password". More recently, multiple security experts such as [[Bruce Schneier]] recommend that people use passwords that are too complicated to memorize, write them down on paper, and keep them in a wallet.<ref>
[http://www.schneier.com/crypto-gram-0105.html#8 Bruce Schneier : Crypto-Gram Newsletter] {{webarchive|url=https://web.archive.org/web/20111115145148/http://www.schneier.com/crypto-gram-0105.html |date=15 November 2011 }} 15 May 2001
</ref><ref name="password_myth">
[https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments "Ten Windows Password Myths"] : Myth #7. You Should Never Write Down Your Password
</ref><ref>Kotadia, Munir (23 May 2005) [http://news.cnet.com/Microsoft-security-guru-Jot-down-your-passwords/2100-7355_3-5716590.html?tag=nefd.ac Microsoft security guru: Jot down your passwords]. News.cnet.com. Retrieved on 2012-05-20.</ref><ref>
[http://www.cryptosmith.com/sanity/pwdilemma.html "The Strong Password Dilemma"] {{webarchive|url=https://web.archive.org/web/20100718174309/http://www.cryptosmith.com/sanity/pwdilemma.html |date=18 July 2010 }} by Richard E. Smith: "we can summarize classical password selection rules as follows:
The password must be impossible to remember and never written down."
</ref><ref>{{cite web |url=http://www.burtleburtle.net/bob/crypto/password.html |title=Choosing Random Passwords |author=Bob Jenkins |date=11 January 2013 |url-status=live |archive-url=https://web.archive.org/web/20100918155208/http://burtleburtle.net/bob/crypto/password.html |archive-date=18 September 2010 }}</ref><ref>
[http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-500.pdf "The Memorability and Security of Passwords – Some Empirical Results"] {{webarchive|url=https://web.archive.org/web/20110219012636/http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf |date=19 February 2011 }} (pdf)
: "your password ... in a secure place, such as the back of your wallet or purse."
</ref><ref>[http://world.std.com/~reinhold/dicewarefaq.html#writeitdown "Should I write down my passphrase?"] {{webarchive|url=https://web.archive.org/web/20090217200722/http://world.std.com/~reinhold/dicewarefaq.html |date=17 February 2009 }}. World.std.com. Retrieved on 20 May 2012.</ref>

[[Password manager]] software can also store passwords relatively safely, in an encrypted file sealed with a single master password.

===After death===

To facilitate estate administration, it is helpful for people to provide a mechanism for their passwords to be communicated to the persons who will administer their affairs in the event of their death. Should a record of accounts and passwords be prepared, care must be taken to ensure that the records are secure, to prevent theft or fraud.<ref>{{cite news |last1=Redding |first1=David E. |last2=Features |first2=AEP published in |title=Your Estate Could Have a Serious Password Problem |url=https://www.kiplinger.com/article/retirement/t021-c032-s014-does-your-estate-plan-have-a-password-problem.html |access-date=17 August 2024 |work=Kiplinger.com |date=19 April 2019 |language=en}}</ref>

===Multi-factor authentication===
{{Main|Multi-factor authentication}}
Multi-factor authentication schemes combine passwords (as "knowledge factors") with one or more other means of authentication, to make authentication more secure and less vulnerable to compromised passwords. For example, a simple two-factor login might send a text message, e-mail, automated phone call, or similar alert whenever a login attempt is made, possibly supplying a code that must be entered in addition to a password.<ref>[https://www.yahoo.com/tech/two-factor-authentication-security-000000679.html Two-factor authentication] {{webarchive|url=https://web.archive.org/web/20160618142745/https://www.yahoo.com/tech/two-factor-authentication-security-000000679.html |date=18 June 2016 }}</ref> More sophisticated factors include such things as hardware tokens and biometric security.

=== Password rotation ===
Password rotation is a policy that is commonly implemented with the goal of enhancing [[computer security]]. In 2019, Microsoft stated that the practice is "ancient and obsolete".<ref>{{Cite web |last=Goodin |first=Dan |date=3 June 2019 |title=Microsoft says mandatory password changing is "ancient and obsolete" |url=https://arstechnica.com/information-technology/2019/06/microsoft-says-mandatory-password-changing-is-ancient-and-obsolete/ |access-date=1 November 2022 |website=[[Ars Technica]] |language=en-us}}</ref><ref>{{Cite web |title=The Debate Around Password Rotation Policies |url=https://www.sans.org/blog/the-debate-around-password-rotation-policies/ |access-date=31 October 2022 |website=SANS Institute |date=March 9, 2020 |author1= Kristen Ranta-Haikal Wilson }}</ref>