Mark Minasi's Windows Networking Tech Page
Issue #43 November 2004

To subscribe, visit To unsubscribe, link to To change e-mail address, switch between HTML or text format, etc., link to  Visit the Archives at  Please do NOT reply to this mail; for comments, please link to  Document copyright 2004 Mark Minasi.

What's Inside

  • News: 
    • One-day security seminar comes to NY next week 
    • Active Directory class comes to NY next week 
    • Windows Security Conference coming to Minneapolis and Arlington, VA November 15 & 18 
  • Tech Section
    • How to (and why to) set 15-character minimum password lengths
  • Conferences
  • Bring a Seminar to Your Site


This month,  But first, a word from our sponsor...

My Seminars are Coming to New York Next Week

Just one more set of sessions this year, New York (Mahwah, actually) in November. Last chance in 2004 to get techie on Active Directory and Windows security.

Seminar: Securing Your Windows Desktops and Servers (November 10)

Everyone wants to secure their network, but many don’t feel that they have the time. I find that a lot of people have a general idea about what they should be doing to secure their networks -- they've heard terms like SMB signing, null session, secure channel, LM hash, and so on -- but haven't the time to sift through the often-contradictory knowledge base articles and the welter of group policy settings, Registry hacks, patches and the like. In just one day, I go through what the big security issues mean and help attendees understand the exact step by step methods that you need to know to make your system more secure.

If you'd like to find out more, please visit

Running a 2003/2000-Based Active Directory (November 8/9)

AD's great, but it can be a fragile flower if not built and maintained properly. Find out how to build, implement, maintain, and repair Active Directory at "Running a 2003/2000-Based Active Directory;" information at .

IDG’s “WinSec 2004” Coming to Minneapolis and Arlington in November 15 and 18

IDG has put together a one-day conference on Windows security starring my old buddy George Spalding and me. In just one day, you’ll get tons of useful security tips, tricks and techniques, and you’ll often be entertained in the process. Visit for more info. We’re only coming to two cities, so I hope to see you in either northern Virginia or Minneapolis.

Tech Section

How to (and why to) set 15-character minimum password lengths

Passwords vex all security people.  But they also vex regular old users, because while most of us would neither know nor care that our security guys had cleverly blocked those lame old LM authentications, the average user is quite chafed when told that he or she has to change passwords every six days, or has to include uppercase, lowercase, and Assyrian letters in that password.

Nevertheless, users do need to create passwords that can't be easily cracked, because it's both true and important to remember this:

Bad passwords beat good security.  Every time.

Security folks know that, and that's why they install password filters that check for complexity and/or minimum length.  It's why they make users change their passwords every few weeks.  It's why they lock people out of their accounts after three bad tries.  But the fact is that those measures are often ineffective, as it sets up a "security geeks versus us" mentality in many organizations.

The problem of passwords has always seemed to me to be based in a simple reality:  it's not a technical problem, in the main.  Instead, it's a human motivation problem.  I like to express this sometimes by saying that it's a "carbon-based problem," not a "silicon-based problem."  In other words, software won't do the job of convincing users to create good passwords nearly as well as training will.

But that doesn't mean that domains shouldn't have any automatic computer-based policies to restrict users from creating too-simple passwords, only that those policies should back up existing password choice training.  But what kind of password restrictions make sense?

Over the past couple of years, I've come to observe a few things about passwords.  (Not that I want you to think that I've come up with this all by myself -- many folks who think about security have arrived at similar conclusions.)

First, complex passwords are a bad idea because while they're hard to guess, they're impossible to remember.  I've only got my tongue in my cheek a little bit when I say that complex passwords are the "Help Desk Full Employment Act of 2004."  And what do we do with hard-to-remember passwords?  Heck, we just write 'em down somewhere.  Maybe on a sticky note.  Hidden under the keyboard... no one would think of that!  And once we write those hard-to-guess passwords down on that sticky note, then they get a lot easier for the bad guys to discover...

Second, complex passwords take too long to enter.  Yes, too-simple passwords are easy to guess, but complex passwords are hard to type, so we type them slowly, and that opens us up to another vulnerability:  shoulder surfing.  If I can look over your shoulder while you type your password and if I can both observe and remember the keys that you strike, then I've got your password.  Having to pause to hit a shift key, or reaching into the numeric row or, even worse, having to hold down the Alt key to enter some code slows down your typing, making it easier for me to discern the keys that you type.

I'm implying, of course, that people can type lowercase a whole lot more quickly.  So allowing people to create passwords that are entirely lowercase is probably a good thing in terms of reducing the chance of shoulder surfing.

Third, if we decide to allow all-lowercase passwords, then we need to require something to make passwords hard to guess, and about all that's left is minimum length.  It's a necessary evil, but perhaps the least painful one.  And, as I'll explain in a minute, longer passwords quickly become computationally impossible to guess, and give us the chance to remove or relax the need for two things that really irritate users:  account lockouts and the need to change passwords frequently.

Fourth, by default Microsoft operating systems retain something called "LAN Manager hashes," a bit of backward compatibility that unfortunately is a hacker's dream -- cracking passwords with LM hashes is child's play.  Ask any security techie to create a "things to do" list on how to harden a Windows system, and I can guarantee that "get rid of the LM hashes" will be somewhere near the top of that list. 

But how to do that?  Well, LAN Manager only supported a maximum password length of 14 characters.  When modern versions of Windows come across an account with a password longer than 14 characters, then they assume that the account's owner doesn't give a hoot about backwards compatibility with LAN Manager servers, and so Windows doesn't bother creating an LM hash.  In my experience, that's the easiest way to eliminate LM hashes -- just create a password whose length exceeds 14 characters. 

With that in mind, here's what I recommend:  do not require complex passwords, but require a 15-character minimum length for passwords.   And yes, I know that sounds unusual, so let's look at it in some detail.

Think "Passphrase," not "Password"

Now, when I say to use 15-character passwords, then you naturally begin casting about for a good 15-character word, and of course there aren't too many of them.  (And seriously, you don't want to use actual dictionary words for passwords in any case.)  But putting together a sequence of words that is longer than 15 characters is simplicity itself:

  • "I think all Apples are lemons!"
  • "ithinkallapplesarelemons"
  • "ithinkallapplesrlemons"
  • "squashroofsarethebest"
  • "squash roofs are the best"

Those sequences are long and nonsensical, so they're harder to guess, and may or may not include spaces, punctuation and case, so  they offer you a range of options that suit the user's tastes.  (And Mac enthusiasts, I was just kidding, no offense meant.)  When speaking to users about how to choose a password, stress that the neat thing about using a nonsensical phrase as a password is that it's the easiest way to create a hard-to-guess, but easy-to-remember, password.  Additionally, as all of those passphrases are longer than 15 characters, then none of them ends up with an LM hash. 

15 Characters are Hard to Crack

Isn't a password -- oops, passphrase -- that contains only lowercase letters childishly simple to crack?  Well, yes, a four-character lowercase-only password would be easy to crack, but a 15 character password would much harder; let's see why.

Suppose you didn't know my password, but you knew that it was just one lowercase character long.  How many guesses would you have to make to find my password?  Clearly you could do it in a maximum of 26 guesses -- a, b, c, d and so on to z.  Now suppose I had a two-character password.  How many options would that have?  aa, ab, ac, and so on, to zz.  That would involve not 26 possibilities, but 26 x 26 possibilities -- 676 possibilities.

To anyone facile with exponents the fact that going from one character to two characters produces a dramatic increase in the number of possibilities, and therefore greatly increases the amount of time that a bad guy has to spend guessing a password, is obvious.  But for those not so comfortable with numbers, let's do a bit more arithmetic to underscore the point.  Things get even better (for us, not the bad guys) when we go to a third character, as there are now 26 x 26 x 26 or 17,576 different possible passwords.  Stop and look at that progression of possibilities -- 26 to 676 to 17,576 possibilities -- and it should be pretty obvious that every time you add a character, you get a big jump in the number of possible password values, making the hacker's job much harder.  15 lowercase characters yields 1,677,259,342,285,725,925,376 possible passwords.  That's about one and half sextillion.  It happens to be roughly equal to the number of atoms in your body, or nearly a trillion times larger than the number of stars in the universe.  In other words, it's a big, big, number.  If someone were to write a program that tried to steal your password by guessing it, and the program were fast enough to try one million passwords a second, then it'd take that program 532,000 centuries to try every possibility.  I'm kind of thinking that by the time that program's done running, you won't much care if anyone guesses your password!

Now, as I know there's a security geek or two out there, let me forestall a tide of quibbling e-mails by adding a bit of data.  The fact is that Windows doesn't really use your password.  Instead, it uses the hash of the password, and you get the hash of a given password by taking the password and stuffing it into a mathematical function.  For example, suppose I were to convert a password into a hash by first converting its letters into numbers from 1 to 26 -- a is 1, b is 2, c is 3, etc.  Then we'd take the password "cat" and hash it by adding 3 to 1 to 20, yielding a hash of 24.  From the point that you create the password "cat," Windows never stores "cat;" instead, it computes the hash and stores just that.  From that point on, whenever you try to log on then Windows doesn't try to match the password that you type in to "cat;" instead, Windows takes whatever password you gave it.  Windows then hashes that offered password and compares the newly-computed hash to the one stored in your account.  So technically you don't have to know my password to log in as me; all you really need is a password whose hash matches my password's hash.

In the case of my example hashing function, notice that the passwords "tac," "atc," "cta" or a number of other possibilities would end up with the same hash of 24.  Does this point to a vulnerability in Windows?  No; instead, it points to a vulnerability in my lame hashing function.  But in reality, it's possible that some hashing functions might allow two different passwords to have the same hash.  It's just not very possible with the particular ones we're using in Windows.

You Can Make Life Easier For Users

Two things I hate as a user are account lockouts and being asked frequently to change a password.  15-character passwords let administrators ease those annoyances for me.

If it's going to take a bad guy a half a million centuries to crack my password, then I'd say that it's safe to either turn off account lockout altogether, or loosen it up to not three or six bad tries but perhaps fifty or more.  Similarly, we can probably allow users to let their passwords go for a few months between changes, rather than the forty or so days that many use.  Sure, we'll be making their lives a bit tougher with the longer passwords, but we can also free them of some annoyances at the same time, and perhaps come out ahead in the deal.

Unfortunately, This Won't Work Without Some Noodling

If you'd like to try it my way, then you probably know that you can use a group policy to set minimum password length.  But if you actually try to create a group policy mandating a 15-character minimum on passwords, then you'll see that the thing that lets you enter the length -- the "spinner control," it's called -- won't let you enter a value above 14.  Some programmer at Microsoft feared for backward compatibility, it seems.  So to accomplish this, we'll need to directly edit the Active Directory with a tool called ADSIEDIT.MSC.  It's in Support Tools, so you'll have to install them (they're in the \Support\Tools folder on your 2000 Server or Server 2003 CD to force a 15-character minimum.

Here are the step-by-step directions, but note that you've got to do this one way on a 2000 system and another on a 2003 system.

Setting a 15-Character Minimum Length On Windows 2000 AD Passwords

  1. Start adsiedit.msc in Support Tools. You'll see server icons for Domain, Configuration, and Schema.
  2. Open the Domain icon and you'll see a yellow folder with the name of your domain.
  3. Right-click that icon and choose Properties. In the resulting dialog box, click the "Attributes" tab
  4. Next to "Select what properties to view:," choose "Both" Drop down the list labeled "Select a property to view," and choose "uASCompat"; its current value will be 1. In the field "Edit Attribute," enter "0" and click the Set button, and then the "Apply" button.
  5. Again, drop down the "Select a property to view" list. This time, choose "minPwdLength" and in the "Edit attribute" field, enter "15." Again, click Set. Click OK.

Setting a 15-Character Minimum Length On Server 2003 AD Passwords:

  1. In support tools, open ADSIedit.msc. You'll see server icons for Domain, Configuration, and Schema.
  2. Open the Domain icon and you'll see a yellow folder with the name of your domain.
  3. Right-click that icon and choose Properties.
  4. In the resulting dialog box, click the "Attribute Editor" tab. Find "minPwdLength;" Double click it.
  5. Change the current value to "15."
  6. Click OK and close Adsiedit.

Unfortunately I do not know of a way to require 15-character minimum lengths on local account passwords, in case you're wondering. 

I've talked about this topic for the past two years and many of you have asked me to put it in writing.  Here it is, I hope you find my password advice useful.  As always, thanks for reading!


Join me at ...

WinSec 2004 Minneapolis November 15, Arlington VA November 18 

The one and only team of Minasi and Spalding, the veritable Martin and Lewis of security talks (he’s Lewis, in case you wondered), come to Minneapolis and Arlington, VA for one day only! Learn to secure your Windows systems and have a few chuckles in the process – find out more at

Bring Mark to your site to teach

I'm keeping busy doing Active Directory and Security seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000, XP, Active Directory and 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, and other organizations that I've assisted, either take a peek at the course outlines at, mail our assistant Jean Snead at, or call her at (757) 426-1431 (only between 11-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I'd like very much to expand this periodical into a useful source of NT/2000/2003/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 36,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care.  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at

To subscribe, visit To change e-mail, format, etc., link to  To unsubscribe, link to Visit the Archives at Please do NOT reply to this mail; for comments, please link to

All contents copyright 2004 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.