The Use of Forced Password Resets

Password Reset

At my first job, all of the staff scheduling was done through a company-owned domain.  You are given a username, you make your own password, and proceed to use that information to log in and check your schedule that was posted two weeks in advance. While I liked being able to check my schedule anytime and anywhere, this domain had one problem:

You had to reset your password every month.

Sure, it’s not the worst thing in the world, but it’s annoying when you’re not able to log in because the password is expired and you can only change it in the workplace. All of that for a small retail job?  Above my minimum wage paygrade.

No one likes having to come up with a new password every month, it’s just annoying.  Many companies chalk this up to the change being for security purposes, but some other companies have started challenging this idea. After all, what keeps a new password from being less secure than the old one?

1.   Why Reset Passwords?

As of now, the biggest argument for forcing password changes across a company is to make sure that hackers can’t rack up storage full of employee’s passwords. For example, let’s say that a hacker is able to steal 5 employee’s passwords on one day, and then 5 others the next.

While this may be bad, a forced password change every month can make sure that these passwords become useless to the person who stole them. This is a legit concern and sounds enticing, but as Microsoft states, this move can actually hurt security more than it can actually aid it.

2.   Removing Recommendations

In April of this year, Microsoft announced that they no longer saw a point in forced password resets, no longer how often they are made. To finalize this announcement, they removed forced password resets from their security recommendation list that companies use to keep their company secure.

While Microsoft emphasized that passwords should still have rules on complexity, length, and history, but forced passwords resets offer no value to security.

As an example, Microsoft flipped the argument FOR forced password resets on its head by outlying the same situation I did.  If a password is stolen and the user’s account is compromised, you’d want to react immediately, not wait a few weeks. However, making your forced password resets happen, let’s say every week, would cause a negative impact on passwords.  Put yourself in that situation; would you keep coming up with a strong, complex, unique password every week, or would you end up using a slight variant of the old password?  Probably the latter, and that’s what a hacker would expect.

Microsoft isn’t even the first company to recommend the removal of forced reset policies.  In 2017, the National Institute of Standards and Technology removed password changes in their password guidance rules. AND before them was Federal Trade Commission chief technologist Lorrie Cranor, who wrote that a hacker who already has a user’s password in possession has will most likely be able to guess the next password back in 2016.

3.   Good Password Habits

For any company figureheads reading this, you don’t need to force your users to come up with a new password every day, week, month, whatever. All you need to do is make sure that every user follows strong password habits.

The obvious rule is making sure that every password is long and complex. The more complex a password is, the longer it takes a hacker to crack it, and hackers tend not to go for accounts that will take them days, if not months, to crack.

Another good idea is to use a random password generator for the user’s passwords. With a random password generator, you can create 32-character long passwords with the click of a button. Saves you the stress of creating a unique password and not worrying if it’s good enough.

It’s time to remove archaic password habits if we want to move on to a new golden age of security. However, with all the attacks going on this month, I feel like that golden age is still ways off. But whatever helps, right?

This post was last modified on July 13, 2019 3:05 PM

This website uses cookies.