You Should Never Change Your Password

**Seriously! A Password Should Only Be Changed If There Are Indications Of Its Compromise**

12 min readApr 2, 2020

The decades-old practice of changing your password every 30 (or 60 or 90 or whatever) days is lousy security. You should pick a strong password and not change it without a good reason to do so. Passwords shouldn’t be the gatekeeper for logins; rather, it should be a password in combination with a “second factor,” such as an app-generated code or a hardware security token.

Seriously! Never Change Your Password!

For years, I have been preaching that you should never change your password. Well, never change it without a good reason to do so, such as a breach that discloses your password or its hash.

Now, please allow me to explain why.

I have passwords that I haven’t changed in decades — passwords on public-facing services, too. And I never intend to change them without a good reason.

I mean, why should I? They are all strong passwords of 60 or more random characters. Or, long passphrases that are easy to remember. I have no indication they have ever been compromised. And, even if they had been compromised, it would give the attacker access to only a single service, as every password-protected system or device I have uses a unique password. Plus, most systems and devices have other layers of defense, which would limit the usefulness of the compromised password.

Many (most?) organizations have a policy requiring users to change their password every 30, 45, 60, or 90 days. Using a calendar as a reason to change your password is one of the dumbest ideas the information security community has ever had, because it encourages poor password hygiene.

Unfortunately, using the calendar as a reason to change your password has become engrained as one of the most sacred tenants of our security mantra. And sacred to the point that the mere thought of abandoning it is enough to get you burned at the stake as a heretic! Even though that is now what NIST also recommends. [See note 1.]

How can never changing your password ever be considered a good idea? Because, for all intents and purposes, passwords have become technologically obsolete. Having a password as your authenticator is, at best, minimal security. In fact, single-factor authentication is a horrid idea. Two-factor authentication is far from perfect — and most of today’s implementations are highly susceptible to attack — but it is exponentially better than single-factor authentication. What is your second factor, and how it is delivered, are the keys to having strong two-factor authentication. [2]

Get Off The Password Merry-Go-Round!

The NIST publication SP 800–63–3: Digital Identity Guidelines is the standard reference all organizations should use as the basis for their identity management, authentication, and authorization policies. The recommendations stated herein are based upon either the NIST recommendations, my experience, or both. [3]

Let’s begin by examining the issues with forcing users to regularly change their passwords.

Even before two-factor authentication became more widely deployed, I rarely changed my passwords anywhere, except for sites that limited me to weak passwords, or for sites that have experienced a breach. I’ve had passwords on some publicly-facing systems and websites that I haven’t changed for over twenty years, and I know they are still uncompromised credentials.

How do I get away with it? Good password hygiene. Five things are key:

I manage all of my passwords (over 400!) using a password database app, so my passwords (with a very few exceptions) do not have to be memorizable. And, for the ones I do have to memorize, I use a long passphrase instead of a password. What passwords do I have to memorize?
◦ The boot decryption password for my computer
◦ My user login for my computer
◦ My password database passphrase
◦ The password for my phone
◦ The password for my tablet
◦ My SSO password for work
And, that’s it. All I have to know is six different passwords to access over 400 logins, each with a different strong password.
My passwords are very long (typically over 60 characters in length) and very complex random gibberish. I use a password generator in my password database app to generate my passwords.
I never reuse a password. Every application, website, computer, or device I have or use has a unique password. Nearly every one also has a unique username and email address. (I have well over 400 email addresses which are aliases for my primary email addresses.)
I know that at most sites I use, the passwords are stored as salted hashes using a very strong password hashing algorithm (either Blowfish, SHA-256, or SHA-512).
I regularly audit account access attempts to check for any activity I did not generate.

Unfortunately, good password hygiene is rare. Very rare, in fact. And, forcing users to frequently change passwords only makes it worse. Adding password complexity requirements to the mix simply exasperates the problem. The result is complex passwords that are difficult to remember, resulting in users creating the weakest possible password they possibly can get away with and writing it down.

Worse still, because passwords are not easy to remember, users tend to reuse the same password “everywhere.” Thus, when their passwords get compromised in one place, the attacker will often try to use that same password elsewhere to access additional information.

Arguably the worst-case scenario is where someone uses their work email address to register at some website and then uses the same password for that website as they do for work. Then, when the website gets hacked and its passwords compromised, the attacker now has trivial access to the user’s work accounts (unless all work accounts and applications are further protected by two-factor authentication). [4]

Another problem that occurs when forcing users to regularly change passwords is that they go out of their way to game the password complexity system (and I’m guilty of that, too!). For example, they pick a base password that meets minimal requirements (I don’t do that!) then make small permutations to it every time they have to change their password. Consider this to be a typical approach of someone who has to change their password once a quarter.

1@m3pA$s15q1
1@m3pA$s15q2
1@m3pA$s15q3
1@m3pA$s15q4
1@m3pA$s16q1
1@m3pA$s16q2
1@m3pA$s16q3
1@m3pA$s16q4

The above sequence of passwords meets all the password length and complexity requirements, and it does not reuse any existing password, so it passes muster with the password complexity algorithms. However, password cracking programs are aware of such “trickery.” The net result is that none of the above passwords are any more robust than the base password (lamepass) and would be cracked in essentially the same amount of time it would take to discover and crack the base password itself.

Nearly every organization is on the “password merry-go-round” that forces regular password changes — which encourages weak passwords. It’s time to get off that merry-go-round!

To make a user’s life easier, organizations should:

Require users to change passwords only when absolutely necessary, such as:
1. The password is discovered to be weak (e.g., in-house password cracking).
2. Suspicion or evidence of the password or its hash having been disclosed.
Use two-factor authentication to further authenticate users beyond their password.
Provide users a password database application where they can securely store and easily access their passwords, and teach them how to properly use it!
Strongly discourage password reuse.
Encourage users to use passphrases instead of passwords.

That’s my summary. Now, let’s look into the details behind those recommendations.

What NIST Recommends

NIST has developed an excellent list of recommendations for creating and managing passwords. The overall guidance can be summarized in a single sentence: To ensure users have strong passwords, make your password policies as user-friendly and as easy to comply with as possible.

Here is a summary of NIST’s Password Recommendations:

No requirement to change any password, except when evidence of a compromise (including password being cracked by internal password strength testing).
Passwords should have a minimum length of 8 characters with a maximum length of no less than 64 characters, with passphrases highly encouraged. Truncation of “too long” passwords is not allowed; instead, the password shall be rejected.
Allowable characters should include:
◦ All printable ASCII characters, including a SPACE. Multiple consecutive spaces can be de-duplicated to a single space, which only counts as a single character.
◦ All printable Unicode characters, including emoji, with multibyte characters counting as a single character. [5]
No known compromised or easily guessed values, such as:
◦ Passwords cracked by internal password strength testing.
◦ Passwords disclosed in previous breaches.
◦ Passwords published as known compromised passwords.
◦ Dictionary words are unacceptable, except when used in long sequences of dictionary words, such as in passphrases. (XKCD explains this concept quite well. Just don’t use “correct horse battery staple” as your password!)
◦ Repetitive or sequential characters or words.
◦ Context-specific words, such as user name, service name, and variations or derivatives thereof.
No other complexity requirements.
When prompting the user to create a password, should the password be rejected, the user shall be given a specific reason for the rejection, then requested to create a password using a different value.
Password hints are not allowed.
When creating a password, users should have an option to view the password typed. [6]
Knowledge-based prompts (e.g., Where did you go to primary school?) when creating passwords are prohibited. [7]
Users should be provided password-strength meters to assist in creating a strong password.
To facilitate the use of password managers, users should be allowed to use the “paste” function when creating or using passwords.

My Caveats

I would add to NIST’s recommendations a few of my own recommendations:

Personally, I never create a password less than 16 characters unless the app restricts passwords to something shorter. In general, I would recommend a password of at least 12 characters, and I strongly recommend the use of an easy-to-remember passphrase no shorter than eight words.
Organizations should provide users password managers and train employees how to properly use those applications.
Users should be encouraged to use their password managers for all passwords — one store for all their passwords, protected by a strong passphrase.
Teach users how to create good passphrases that are easily remembered so that their password manager is adequately protected.
If the password manager supports two-factor authentication, or it allows the use of biometric identification, enable it.
Users should be strongly discouraged from using a browser’s “remember password” feature. Instead, the password manager should be used to store all passwords — that is, keep all passwords in a single, well-protected, password database. (In fact, for corporate compute resources, I would highly recommend this corporate-wide disabling of the browser “remember password” features.)

Authentication

How users are authenticated is actually more important than is their password. NIST also offers guidance from the authentication side of the issue. Significant recommendations include:

It is mandatory that passwords are never stored, even when encrypted. Instead, salted password hashes must be what is stored. [8]
Transmission of passwords during authentication attempts shall only occur through secure (encrypted) communication channels. [9]
Two-factor authentication should be universally deployed and be required for every authentication attempt. [2]
◦ SMS has been deprecated as a means of providing a second authenticator.
Biometric measures have been designated too weak to use as an authenticator. [10]

To the above recommendations, I would add the following:

Buy an FPGA-based or GPU-based password cracking box and continually try to break your user’s passwords. Word of warning: Run this system on a sneaker-net, so any cracked passwords cannot leak to your LAN.
Ensure that your organization has eliminated authentication protocols that leak passwords or password hashes over your LAN (e.g., NIS).
Constrain the use of SSO to the greatest extent possible short of inciting a user rebellion. [11]

Summary

If you remember one only thing from this posting, this should be it: To ensure users have strong passwords, make your password policies as user-friendly and as easy to comply with as possible.

Passwords have always been one of our weakest forms of security. As a single authentication factor, they have become technologically obsolete.

The latest NIST password guidance obliterates all of our past security mantras concerning passwords. Its guidance will require most organizations to completely rethink their password policies and potentially require significant resources to implement those changes. However, we really don’t have any choice: the way we currently manage and use passwords is so horridly broken that passwords have become nearly worthless as authenticators.

The most significant changes in the NIST guidance are as follows:

Never change passwords unless there is evidence of a compromise
No password complexity requirements beyond:
◦ A minimum length of 8 characters, with a maximum length not less than 64 characters
◦ All ASCII and Unicode characters are allowed
◦ No known bad passwords
Two-factor authentication has become a necessity, but using SMS for the second authenticator is out.

The new NIST password guidance is without question one of the biggest rethinks ever of our security mantra. Passwords have become increasingly weak (i.e., next to worthless) for over two decades now, so this new guidance is well past due, but highly welcome.

Thanks, NIST! Job well done.

Notes

NIST SP 800–63–3: Digital Identity Guidelines is a 4 volume set of guidelines for establishing digital identities and authenticating them. It is considered the industry standard best-practices guide for identity and authentication.
See the blog post, Two Factor Not, for a discussion of two-factor authentication and its strengths and weaknesses. (Coming soon!)
The majority of these recommendations are detailed in NIST SP 800–63B Authentication and Lifecycle Management, but some draw from recommendations in other NIST SP 800–63–3 guidelines.
All organizations should have a policy that prohibits the use of work email addresses from being used to register for any website. Why? Because this provides a potential attacker with information about the applications and resources used by the organization, which enables the attacker to build a detailed list of potential attack points into an organization. For more discussion on this topic, see my blog post, LinkedIn Is Your Worst Security Threat (coming soon!).
Unicode characters count as a single character and should be normalized prior to hashing. To quote NIST SP 800–63B, “For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character. If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15. This process is applied before hashing the byte string representing the memorized secret. [Users] choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by [different operating systems], which can affect their ability to authenticate successfully.”
To quote NIST SP 800–63B: “In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry.”
In general, knowledge-based authentication is a bad idea. There are simply too many ways to find the answer to knowledge-based prompts and for an attacker to thus social engineer their way into authenticating as that user. Whenever I am asked one of these “security questions,” I always make up completely bogus answers, and if the system will accept it, I use a very long string of completely random characters created by my password generator. (Naturally, store any bogus answer in your password database so you can provide your answer when prompted to do so.)
To summarize what NIST SP 800–63B specifies: “Memorized secrets 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. … The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output. … The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator. … [T]he iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.”
NIST requires the password to be transmitted through a secure channel. Most implementations would meet this requirement using TLS, which in many cases, can be rather easily hacked. My recommendation is for the client to hash the password (server would have to provide salt and other parameters), and then send only the hash to the server. Thus, the password is never exposed, even if the secure channel should be compromised.
As discussed in the blog post, There Are Only Two Ways to Authenticate, biometrics are identifiers, not authenticators. NIST has basically agreed with this assessment, as they allow biometric measures to be used in authentication, only if the primary authentication factor is a “something you have” type of factor, such as a security token. Biometrics are simply too easy to attack to be allowed as an authenticator. (TL;DR. Authenticators must be deterministic. Since all biometric measures are deterministic, they not suitable as authenticators.)
I will discuss issues with SSO in the upcoming blog post, Single Sign-On: A Hacker’s Dream Come True.

Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.

About The Blogger