Creating Sane Password Policies?

Xenocide asks: "Occasionally, while using Windows here at work, my LAN account gets locked out for one reason or another (three tries and you're out). This requires me to contact our Help Desk and have the password reset. Now, because the server administration thought it was a good idea, old passwords cannot be used again. After talking with a Help Desk person, they said there was a large increase in password resets lately. It seems to me that if you make password policies too outrageous, users will find a way to circumvent the system. Not to mention that this increases support costs. I was wondering, what password policies do other companies use? Also, how do you convince the administrators to implement reasonable ones? "

Comments

Re:Alternatives (circumventing the system?)

[chuck]

It seems to me that if you make password policies too outrageous, users will find a way to circumvent the system

Like what, actually remember their passwords?

No, more likely write them down. When you push your users over the brink like that, that's what happens. They just figure it's easier to put it on a post-it and stick it on their monitor. Because they aren't so insane about security and don't worry about if someone breaks into their account and steals their useless files... You must always look at things from the user's perspective. Not yourself, I mean a normal user... :)

-Chuck

Sensible Password Policies

[jd]

I've never seen a company with one of those. However, never reusing a password is clearly not sensible. (And, yes, I've circumvented THAT one many a time.)

The best password policy is to strictly enforce:

• Non-trivial passwords. (ie: Must NOT be crackable using a standard dictionary cracker.)
• Should include both upper and lower case, at least one numeral (OTHER than at either end, at the end of a dictionary word, OR as a trivial "337" substitution) and AT LEAST one non-alphanumeric character (same as for numerals).
• Passwords should expire after a sensible period of time, and not be reusable within that same length of time. What is sensible depends on the level of security involved. Secretarial work probably doesn't need an expire time less than 6 months. Top Secret 007-type work would probably use an expiry time of 12 hours or less, with OTP encryption on top of it.
• People who pick stupid passwords should be forced to watch Bill Gates' video dispositions every day for the next week. With an exam afterwards.

sane password policies...

[millia]

this is the reason i am happy beyond belief that biometric devices are below $100 now.

password policies are always a bone of contention, no matter what level of security you implement.

I personally think 3 tries before lockout is too few on a windows system, first, especially if you're dealing with windows 95/nt combinations, since you can have multiple, different passwords. throw in a connection to a legacy system, and it's chaos.

Also, reusing passwords shouldn't be set to a high value, but perhaps only to a 10 use value.
We required passwords to be changed once a month.*

The most important thing is to teach people how to create passwords that are long and sufficiently complex, yet follow a system that can be cycled through.

Example: you're a baseball fan. Use team names, and insert random numbers in the middle. i.e.:
atlanta58braves
and shorten as needed. Next month you can switch to the (hated) Yankees, for example.

We required 10 digits at least, with numbers. People freaked out at first, but once you showed them how to do it, we had fewer problems. Well, once we fixed a dll problem that wouldn't allow you to change both 95 and NT passwords simultaneously. But that's another issue...

* The worst disaster we ever had was when the power went out at our central office 5 minutes after we implemented the policy and 2 minutes after we sent out the email telling people how to do it. When their systems came up, they of course had to change their passwords, and boy howdy, that was NOT a fun day since most did it wrong, since this was pre-DLL fix.

Alternatives (circumventing the system?)

[dlc]

With a password policy like that, I have to ask: has your network been broken into lately? Do you work for a government contractor or something else that deals with sensitive data, like a bank? Otherwise, in normal, day-to-day use, this sounds like overkill. If the admin is that worried about passwords, get a strong firewall product to protect your network from the external world, so that you can lift some of the password restrictions for local users.

If your network has been broken into lately, it sounds like an overall security audit is called for -- most of the time the problem is not that passwords aren't strong enough, but that vital services are vulnerable (holes in FTP or Web servers, for instance, or Sendmail improperly configured, or SMB over the internet). The problem could could also be that the users are not careful with their passwords -- you can have the strongest password policy in the world, but if Joe in Marketing keeps giving his password to his brother every time he changes it, you will continue to have problems.

If you are working for an organization that has sensitive data and resources to protect, there are many methods of authentication that don't require passwords -- someone already mentioned biometrics. I prefer using encrypted connections, such as SSH with key exchanges, where passwords are not send (passphrase are maintained on the local machine only and not sent over the network). Many of these are transparent to the user (though of course totally different to the machine, often requiring installation of specialized clients or other software).

• It seems to me that if you make password policies too outrageous, users will find a way to circumvent the system

Like what, actually remember their passwords?

Cthulhu for President!