[unisog] Password auditing

Dave Dittrich dittrich at u.washington.edu
Fri Jul 1 17:25:57 GMT 2005

> Both Steve and Dave make good points about dictionary based auditing
> but I worry that that would not have helped in our case earlier in
> the week.  Dictionary based attacks and defences are only as good as
> the dictionaries you have access to and unless you can add in what
> the latest attack tools are using you are going to miss things.
> Hmmm... Dave do you know if anyone collects these lists and colates
> them?  I've go one hot from the forensics ;)

Yes, I agree that the quality of the dictionary matters for general
checking.  Once an attacker's dictionary is found, though, that is the
next best thing.  I'm not aware of any public efforts on behalf of the
security community to do this, but I have seen a few "hacker" web
sites that include dictionaries. I'm not sure where the best place
would be to centralize something like this.  The flip side is who
benefits most from doing this: attackers, or defenders?

> "My' way would give you both dictionary based defense and a
> selectable level of brute force protection as well as alerting the
> admin to additions and deletions to the user list  but at the cost
> of fairly intrusive mechanisms (for want of a better term).
> It may turn out that the best way of doing this is to use a standard
> integrity checking system to detect changes in the password file and
> prompt admins the check it.

Good point.  Tripwire, or similar integrity checking programs, are
another good defense (although someone who has gained root level
access, and using a kernel level rootkit, could defeat this by
redirecting reads of the password file to a copy of the original one
by anything other than the passwd program.)  Limiting the number of
login attempts to three to five failures before breaking the
connection, and adding increasing delays on the order of tenths of
seconds to seconds between attempts, slows down dictionary and brute
force attacks, but doesn't really affect the user who is having
trouble figuring out the "k" key is sticking.  Adding an alert sent to
the admin after ten failures on a single account (not even locking it
down) is another good defense.  The combination of these would give an
admin enough time to identify the attacking host and block it at the
border by null routing, firewall ACL, or just report it to the site

Dave Dittrich                           Information Assurance Researcher,
dittrich at u.washington.edu               The iSchool
http://staff.washington.edu/dittrich    University of Washington

PGP key      http://staff.washington.edu/dittrich/pgpkey.txt
Fingerprint  FE97 0C57 0843 F3EB 49A1  0CD0 8E0C D0BE C838 CCB5

More information about the unisog mailing list