Password expiration policies [closed]

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.


Solution 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.

Solution 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.