Password expiration policies [closed]

Question

Having just received an email from a supplier informing us that they would be forcing us to change our password every six months, I'm curious to see what password expiration policies people use and why they use them.

Answer 1

There is a fine line here between never changing it and changing it too often. Having the same passwords for years is often not a good solution, especially if it's publicly available. But forcing a rigid policy of changing it too often also has bad side effects. One place I worked at, forced all users on the internal network to change passwords every 6th week and the passowrd couldn't be the same as the six previous passwords. Three wrong passwords locked the workstation, and the IT staff had to unlock it. Which resulted in everyone writing the password on Post-It notes hanging on the screen or placed in their drawer. Nightmare.

I'd say changing the password once every 6 months should be sufficient. This will avoid those dreaded Post-It notes.

Answer 2

I would suggest employing a bit of math that takes into account your minimum password complexity, how fast an attacker could guess passwords, the number of unlocked accounts you have, and some informed information about your risks.

Hopefully you have some sort of rate-limiting for password guessing. Typically that would be via something that temporary locks accounts after some number of bad passwords.

And hopefully you have some sort of password-complexity requirements so that "A" and "password" aren't allowed.

Let's assume that after 30 password failures in 10 minutes you will lock an account for 20 minutes. That effectively limits the password guess rate to 174 per hour, or 4176 per day. But let's assume it's per user.

Let's assume you require 8+ character passwords containing upper, lower and a number, and that you do some dictionary checks to ensure that those passwords are reasonably random. Worst case your users all put the one upper, and one number in the same place and your attacker knows it, so you've got 10 * 26 ^ 7 (80G) possible passwords. Best case is 62^8 (218T).

So, an attacker trying every possible password would hit them all within 50,000 years in the worst case, and almost 600 million millenia in the best case. Or, to put it another way, given one year they'd have between 1 in 50,000 and 1 in 52,000,000,000 of guessing. If you have a userbase of 50,000 it's almost guaranteed that in the worst case they'd get into one account per year and have roughly a 50% chance of getting one account every 6 months.

And if you had no rate limiting and an attacker could guess a billion passwords a day? A one in 600 chance of getting into an account in a year, or a virtual guarantee of getting about 80 out of your 50,000 users every year.

Work on that math, and figure out where your acceptable risk level is. And remember that the shorter you set it, the harder it will be for users to remember and the more likely they'll have it written down someplace convenient for an on-site attacker.

As an added bonus: if somebody is trying thousands of passwords per user per day against your systems, I really hope you have some sort of monitoring that would pick that up.

EDIT: Forgot to mention: our actual policy is 90 days, but that has everything to do with findings by misguided security auditors and nothing to do with reality.

Answer 3

90 days seems to be sufficient for most scenarios. My biggest concern is password complexity. More than the time frame issue in generating post-it notes is the forced complexity. It's one thing to avoid dictionary words and another to have special characters, but when you start saying that no characters can repeat or be in ascending/descending order, you have made your users lives difficult. Add that to a short password life and you've just welcomed in more issues.

Answer 4

Password expiration is annoying and reduces security.

Password expiration defends against the situation where an attacker has compromised a user's password once already, but does not have a mechanism of finding out what it is on an ongoing basis (e.g. keylogger)

However, it also makes it harder to remember passwords, making it more likely that users will write them down.

As defending against an already-compromised password is not really necessary (you hope), I consider password expiration useless.

Get users to choose a strong password to begin with; encourage them to remember it, then don't require them to change it, ever, or they will end up writing them down everywhere.

Answer 5

If you have a device that needs "high to ultra-high" security guarantees, you are better off using a hardware token that generates one-time passwords instead of relying on having password expirations.

The main "win" for a password expiry system is that you WILL, eventually, have an account disabled if the account-holder leaves the organisation, as an extra "check and balance" to "the account should be disabled when the account-holder leaves".

Enforcing password expiration leads, at best, to high-quality passwords written down and in the worst case to bad passwords (at a previous workplace, once we were forced to use password expiration, I ended up using (essentially) prefixJan2003, prefixFeb2003 and so on, as my preferred method of generating passwords (48 random bits, Base64-encoded) doesn't scale to "new passwords every month").

Answer 6

I think if you ask 10 different security professionals this question - you would get 10 different answers.

This greatly depends on how critical the asset the password is protecting.

If you have a highly secure asset, you need to set your password expiration policy short enough so that any outside intruder will not have time to brute force a password. Another variable in this situation is what level of complexity is required on the passwords.

For low to medium security systems I think a 6 month expiration policy is very fair.

For high level security I think a month would be better - and for 'ultra' secure installations even shorter time periods would be expected.

Answer 7

We enforce a 90-day password expiry on everyone here, (including ourselves.)

Mostly because it's simply best-practices. Chances of someone using a "weak" password, vs. a stronger one is greater and the longer you leave it the same would possibly result in a long-term, undetected security breach.

Answer 8

We expire passwords yearly and require strong (preferably random) passwords longer than 10 characters. We run dictionary attacks on people's passwords when they change them. We keep past password hashes so that passwords can't be re-used. We also check for potential dates in the password like vatine said. ;) The last was my addition...

At a former job, we did try expiring more frequently at a new network security administrator's behest -- every two months. Two weeks after the first forced change, I took him around our administrative offices and we looked under people's keyboards and mousepads. Over 50% of them had a password written on a post-it underneath. He was happy to loosen the policy after we sat down and talked to the administrative staff -- their opinion was that they didn't have it long enough to memorize.

Most of our stuff these days is single sign-on within a few silos. Campus resources (rarely used for most people) are in one silo and that password is managed by our central IT group. Departmental resources (used daily -- machine login, email, website editing, photocopier) is a password managed by our group, also expired yearly. If people gripe about being frustrated, we point out that they really only have one password to remember.

These days, I generate an md5sum on a random file in /var/log and use a subset of that for my passwords.

Answer 9

We had a lot of discussions about this a couple years ago when we started a password expiration policy. We had just finished a l0phcract run with rainbow tables against the AD tree to see just how bad it was, and it was pretty horrific. An eye-bleeding number of users still used their "helpdesk temp" password after calling in/dropping by for a password reset, something horrendous like 30% used "password" or some variant as their password (p@$$w0rd, etc). That convinced management that this needed to happen.

Being higher ed, we had summer to contend with when selecting an interval. A lot of our faculty don't teach during the summer, so our helpdesk had to brace for the, "I forgot my password" calls as they all come back in September. I think, and I may be wrong, that our interval is 6 months with a summer-quarter exception. So if your 6mo password expiration has it expiring in mid-august, it would be randomly reprogrammed to reset in late Sept to early Oct.

A better question is how often your utility account and admin passwords get rotated. All too often those seem to get exempted from password change policies. Who wants to go through all those scripts for a utility account password change? And some backup systems make it hard to change used-passwords, which provides a disincentive to change admin passwords.

Answer 10

One major problem with expiring password frequently is that people will struggle to remember them, so you'll either have people using weak or similar passwords, or if your policy doesn't allow this, they will start writing down the passwords to help remember them. You'll also have more password change requests, when people do forget them.

Personally, it depends on what the password is used for, but I tend not to keep a password more than 3 months, unless it's a complete throwaway account. For higher risk stuff, every month or so is good, and defiantly change it if someone else who knows it leaves. Because I work in a small computer support business, we have multiple passwords that are shared between lots of people, so we don't want to change them very often, because of the disruption it can cause.

Answer 11

Interesting comments so far. Of course why is it always the debated that remembering passwords is an technical versus non-technical personnel issue in a company? What does someone's ability with computer hardware/software have anything to do with their ability to take security serious? Will a non-technical person give out their Credit Card or Debit Pins #? Also, people placing passwords on post-it notes on their desk should be grounds for dismissal. Its amazing how people's memory will improve when they actually realize security is important and must be taken seriously. I see it no different that the role of dress codes and conduct policies at work. Follow the rules or goodbye!

Answer 12

I think that having a more secure password is much more important than frequently changing it, but both are definitely necessary for a secure system.

The argument goes that complex passwords are difficult to remember, and lead to employees writing them down. My belief on this is that the vast majority of the attacks come from the outside, and even writing down a complex password and taping it to your monitor is more secure than having a simple password memorized.

Answer 13

I'm implementing one-time pad and time-token based authentication, so, in theory, every time the user logs in.

Though this is arguably off-topic, a one-time pad seems to be a superior solution.

Similarly, and more basically, ensuring that the user creates a strong password, and understands the ethic behind your security policy (don't write it down, don't make it your birthday, don't give it to anyone) will go much farther than simply forcing them to change it every nth time-based interval.