Mark Minasi's Windows Networking Tech Page
Issue #43 November
2004
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
To change e-mail address, switch between HTML or text format, etc., link
to http://www.minasi.com/edit-newsletter-record.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp. 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
News
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
www.minasi.com/secoutln.htm.
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
www.minasi.com/2003outln.htm .
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 http://www.winsec2004.com 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
- Start adsiedit.msc in Support Tools.
You'll see server icons for Domain, Configuration, and Schema.
- Open the Domain icon and you'll see a yellow folder with the name of
your domain.
- Right-click that icon and choose Properties. In the resulting dialog
box, click the "Attributes" tab
- 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.
- 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:
- In support tools, open ADSIedit.msc.
You'll see server icons for Domain, Configuration, and Schema.
- Open the Domain icon and you'll see a yellow folder with the name of
your domain.
- Right-click that icon and choose Properties.
- In the resulting dialog box, click the "Attribute Editor" tab.
Find "minPwdLength;" Double click it.
- Change the current value to "15."
- 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!
Conferences
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
http://www.winsec2004.com.
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 www.minasi.com/presentations.htm, mail our assistant
Jean Snead at Assistant@Minasi.com, 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 http://www.minasi.com/gethelp and
please join us at the Forum with technical questions at www.minasi.com/forum.
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2004 Mark Minasi. You are encouraged to quote
this material, SO LONG as you include this entire document;
thanks. |