Web Informant #267, 22 October 2001:
Let's talk about passwords

Repeat after me: I am not getting more paranoid. I am not getting more paranoid. I am not ... Sorry, I had to just look over my shoulder for a moment, I thought someone was in the room behind me.

Yes, we do live in different times. And many people are getting a bit more jittery. In my high school networking class, one of my students asked me the name of my pet: turns out that this is a common password and he was interested in hacking into my web server.

That got me thinking. Maybe it is time to take a more careful look at password policies in general. And if you run your own web site, or are responsible for the servers in your organization, maybe a little paranoia will be good for your overall security and peace of mind.

Beefing up your password policy is something so mundane, so simple, but yet so overlooked. I know, password policies are about as dry a subject as toast these days, but nothing can so easily change your web site from a fortress to a wide open game preserve for script kiddies to play around in. And the difference between a good password policy and a bad one can so easily be implemented without much additional effort on your part. It isn't expensive, it isn't time consuming, and it can be done with a minimum of skills.

There is one problem, however: you need to understand that there are some tradeoffs. The more stringent your password policy, the greater the probably of the password Post-It. This refers to the act of users writing down their passwords on a small sticky note and attaching it to their monitor for all the world to see. I once attended a computer security conference at a convention center in Boston. Walking to the conference, I passed a trading room for a large financial services firm, with large picture windows facing the street. It was easy to pick up these notes with passwords, and I am sure if someone really wanted to grab a password it wouldn't take too much trouble.

One suggestion before we go any further: If you have an account called 'test' and it's an administrator level account, don't give it a password of 'test'. Same goes for 'password', 'admin', and other similar and familiar words. You would be amazed how often this happens.

While I am not an expert with Unix, a good place to start to educate yourself is this article.

Let me show you what you need to do on Windows Servers. Depending on how you installed your server (either as a standalone server, part of an existing NT domain, or running Active Directory) and depending on whether you have Windows 2000 or NT Servers installed, you will have to hunt down the Password Policy and Account Lockout Policy sections (try looking for Users and Groups, Local or Domain or Domain Controller Security Policy or Security Settings). There are several entries worth taking note of here:

• Maximum password age -- the number of days that passwords expire and must be changed. An entry here of 0 means that passwords never expire. I recommend 90 days as a good starting point.
• Enforce password history -- this means the server will remember a set number of passwords, so that users can't switch their passwords among this set but must make up new ones. Users therefore can only reuse a password after changing it a number of times. I recommend an entry of 8 here.
• Minimum password age -- password changes are allowed either immediately or after a certain period of days. This prevents users from quickly switching passwords back to something that is less secure and more memorable. I recommend 10 days here.
• Minimum password length -- the minimum number of characters long for each password. I recommend eight character passwords, although there is some discussion about 7 character ones being better because of how earlier versions of Microsoft LAN Manager worked in encrypting them. On NT, you can permit a blank password, and obviously you shouldn't enable this feature. See Eric Schultze's SecurityFocus article on this.
• Passwords must meet complexity requirements -- when enabled (which is my recommendation), this will make guessing passwords harder and also mean that users will have to create passwords using non-alphabetic characters. Complex passwords also don't contain any part of the account name and are at least 6 characters in length.
• Store passwords using reversible encryption for all users in the domain -- This has no effect on what passwords users choose. I recommend you leave this disabled, unless you have an application that requires this feature.
• Password never expires -- this should never be checked, unless it is for an account that is used by a system service.
• Account lockout threshold -- accounts are locked after the specified number of incorrect login attempts. I recommend a value of 3 here. On NT, you have to explicitly enable the lockout mechanisms.
• Account lockout duration -- accounts are locked for a period of minutes after failed login attempts specified above. I recommend 60 minutes here.
• Reset account lockout counter after a specified number of minutes. I recommend 60 minutes here.

There is a lot more that can be said about passwords, and how NT and 2000 store passwords and how you apply additional patches to strengthen your defenses. Some good places to read up on this include this SecurityFocus article, which mentions running the Syskey utility to further encrypt the user accounts database:

In the meantime, a little paranoia can be a good thing. And watch out when you do implement stronger password policies for those little yellow notes to appear around your company.

To subscribe, send a blank email to
informant-subscribe@pez.oreillynet.com

To be removed from this list, send a blank email to
informant-unsubscribe@pez.oreillynet.com

David Strom
david@strom.com
+1 (516) 944-3407
back issues
entire contents copyright 2001 by David Strom, Inc.
Web Informant is ® registered trademark with the U.S. Patent and Trademark Office.
ISSN #1524-6353 registered with U.S. Library of Congress.