Forced Password Rotation == Incrementing

Some organizations still force a user to change their password at a defined interval. This is not only ineffective, but it is also detrimental to the security of users’ accounts.

This is a follow-up to another article we wrote last year, A Sensible Password Policy. It might be beneficial to review it first if you haven’t already.

When we perform penetration testing or red teaming against a client with a forced password rotation policy, there is a common and pronounced pattern to users’ passwords. That pattern is known by many as “password incrementing”.

What is password incrementing?

One form of password incrementing is when a user establishes a base password and then adds a chosen number of characters (typically numbers) to it that can be changed (or incremented) every time they are forced to change their password. Most commonly, this is one or two numbers added to the end of their base password, but sometimes can be the beginning or even somewhere in the middle. The key is the position and number of those characters are constant and predictable.

As an example, Jane sets her password to “Password01” in January, and then increments it to “Password02” in April when she is forced to change it. In our experience, “Password” is often seen as “Secret”, “Welcome”, “Letmein”, and a few other common base words. Sometimes, it’s literally the word “Password”. About a fourth of the users will be a little more unique and use the name of a child, spouse, or pet, all of which are typically easy for an attacker to discover (ex. spokeo.com)…albeit, with a few extra minutes of work.

Some users utilize a different, yet predictable, incremental pattern that would still qualify as password incrementing. Instead of a static base word, as seen in the example above, they will use a season (Spring, Summer, etc.) or month (January, February, etc.) for the base word and tack on a few predictable numbers or special characters in order to meet password complexity rules. In this scenario, the base word changes every forced update, which one would think would be more secure. On the contrary, though, the predictable nature of what and when that base password changes to makes this the least secure and most common to crack first during an attack.

As an example, John sets his password to “January2020!” in…you guessed it…January of 2020, then changes it to “April2020!” in…yep, you guessed it again…April of 2020. As mentioned above, in addition to using the month’s name, users will also use the name of seasons.

Metrics

In our experience, the two example formats above – static base name and season/month name – account for nearly three-fourths of the passwords in a typical organization which forces their users to change their password every 60-90 days. Nearly every person in the one-fourth still increment, but they use a base password that is not common or easily discoverable, and, therefore, not as easy to predict. Of course, there are those who use randomly generated passwords stored in a password manager, but those percentages are very small.

Bottom line

When an organization periodically forces a password change, only a few percent of the users come up with a truly unique password each time.

Recommendation

Please do not force periodic password changes on your users. As we pointed out in our above referenced article, an organization has but seconds or minutes to force a password change when a password is compromised, in order to do any good. Forcing a password change when there is no evidence of a compromise is not only worthless, it is probably detrimental to the security of your organization.

Conclusion

If you are interested to know how your network services and web apps would perform against these types of attacks, but do not have the expertise or resources to do so, contact PEN Consultants today!

Featured image is a derivative work from the following images: TBIT @ https://pixabay.com/illustrations/login-password-log-sign-on-turn-on-1203603/