Beware the Ides of March

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  23-March-2003                                                   |
|  http://www.hackinglinuxexposed.com/articles/20030323.html       |
+------------------------------------------------------------------+

This issue sponsored by Open Source Web Development with LAMP

OSWD w/ LAMP by James Lee and Brent Ware presents a comprehensive
overview of LAMP technologies - Linux, Apache, MySQL, Perl, PHP, WML,
Embperl, and Mason - and allows the reader to decide which tool may
be appropriate for the particular task at hand. It focuses on the
most important core material necessary so that developers can "hit
the ground running" and begin buliding applications right away, while
improving reliability and dramatically cutting costs.

For reviews, sample chapters, or to order, go to
www.opensourcewebbook.com

--------------------------------------------------------------------

Beware the Ides of March
By Brian Hatch

Every year on March 15th my mother would act out the death of Julius
Caesar. From the warning he received as a young child from the grimy
soothsayer, his speech to his "Friends, Romans, Countrymen", the
assassin sneaking up behind him for the strike, a truly pained "Et tu
Brute?", and a couple of final gurgles. Oh, the last death throes of
a great ruler, acted out yearly in the kitchen, or hallway, or -- if
you were really late waking up -- your very own bedroom. Now that
we're out of the house, March 15th means an early morning phone call
from home, but it's lost none of it's potency.

Now you might be wondering why in the heck a security column should
begin with the Ides of March. Or, even more interestingly, why it
would begin with the Ides of March a week after the Ides of March.[1]
Well, fear not, I'll get to the point.

I can't imagine what you might do should you be woken some morning to
the retelling of the fall of an empire, but to me it reminds me that
it's time to change my passwords. Most security folks suggest you
change your passwords at least once or twice a year. One of the most
frequently suggested times are the change to and from daylight
savings time. But for me, it's the Ides of March.[2]

So what makes a bad password? Anything associated with you or your
likes, desires, or quirks. Anything out of a dictionary in any
language. The name of your relative, pet, significant other,
favourite movie, phone number, birthday, or favourite colour. These
things are either easy to guess if someone knows you, or are able to
be cracked fairly easily by password guessing programs.

And most importantly, any password that you've used before is right
out.

So what makes a good password? It depends somewhat on your
password-hashing algorithm. Most new Linux installs use strong
password-hashing algorithms such as MD5, which can take an infinite
length password. Older installs used the traditional DES algorithm,
which only allows 8 character passwords. It's best for you to ask
your administrator which kind of hashing algorithm is used on the
system before you choose a password.

If you are the administrator, it's not too hard to see which kind of
hashing algorithm is the default. For example, change the password
for jdoe and then do the following:

  old_des_style# grep jdoe /etc/shadow
  jdoe:m1kbsnKnULUKs:12133:0:99999:7:::
       ^^^^^^^^^^^^^
  md5_style#     grep jdoe /etc/shadow
  jdoe:$1$e0/v1t9O$y/SxZxbiHsesW5HbeZRHq0:12133:0:99999:7:::
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(I've underlined each password hash above with caret symbols to make
it easier to see them.)

On the first host, the passwd program is configured to use the older
DES-style password hashes. The password hash is the 13 character long
string "m1kbsnKnULUKs". The second host uses MD5 hashing instead, as
can be seen by much longer hash "$1$e0/v1t9O$y/SxZxbiHsesW5HbeZRHq0".
There are other possible password hashing routines[3] but these are
the two you're most likely to have available.

So, once you've determined which kind of password hashing algorithm
your machine uses, what makes a good password? Since each type of
algorithm has different characteristics, here are my recommendations:

Traditional DES-based

  * 6 to 8 characters long
  * No more than 8 characters - extras are ignored
  * At least one character from the four following characters
    classes:
      + Lower Letters ( abcd...wxyz )
      + Upper Letters ( ABCD...WXYZ )
      + Numbers ( 1234567890 )
      + Other Characters ( !@#$%^&* etc )
  * A good way of creating a short but entropy-laden password is to
    take the first letter of each word in a phrase, and add some
    weird characters to it or convert some letters to other
    characters, for example:
   
      + Where did I leave my keys? => WdIlmk?
      + Linux kicks Window's a**. => lKW's&**
      + Open Source and LAMP make my day => 0S&lmmd%

MD5-based

  * A short password (6-8 chars long) that satisfies the above rules,
    or
   
  * A 'passphrase' which
      + Should be at least 15 characters long (15-40 is a good rule
        of thumb)
      + Has a variety of characters, not simply 'aaaabbbbcccc' -- use
        at least two or three from the four classes above.
      + Can incorporate dictionary words as long as you have a long
        enough passphrase. For short passwords, using dictionary
        words is a horrible idea, but with long passphrases it is not
        as vulnerable to brute force measures. For example:
       
          o Bridge-dare!prone
          o I'd_rather-run=DJBDNS
          o March^last(if you ask me)

The most important thing, regardless of which password hashing
algorithm your system uses, is that your password should be easy for
you to remember[4] but hard for others to guess or crack.

And the other most important thing -- never use your password on an
unencrypted channel. Use SSH for logins, and SSL-enabled versions of
any protocols that use passwords, such as IMAPS instead of IMAP, or
STARTTLS for SMTP. A cracker doesn't need to guess or crack your
password if he can read it on the wire directly.

NOTES:

[1] I thought I should finish up that three part SSH Port Forwarding
thread before I accosted you with sentimental childhood memories.

[2] I use SSH keys for almost all my connections, and I barely ever
log in using an actual password, so the chances they'll be snagged
are pretty low. Besides, I get copies of all the logs showing my
login times and methods, so I'd notice pretty quick if any of my
passwords have been compromised. I keep my SSH identities on my
laptop only, and change them more frequently.

[3] For example, Owl Linux supports traditional DES, BSDI-style DES,
FreeBSD-style MD5, and OpenBSD-style Blowfish hashes.

[4] If you need to write it down on a sticky note, you're in trouble.

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. His wife fears that he will
continue the yearly ritual with their lovely and impressionable
daughter. But hey - it's history, educational, and even contains a
little Latin. Can't be all bad, right? Brian can be reached at
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.