[unisog] Password policies

Jim Dillon Jim.Dillon at cusys.edu
Mon Apr 24 16:45:39 GMT 2006


Good to hear from you.  Some thoughts inline.


Jim Dillon, CISA, CISSP
IT Audit Manager, CU Internal Audit
jim.dillon at cusys.edu

-----Original Message-----
From: unisog-bounces at lists.sans.org
[mailto:unisog-bounces at lists.sans.org] On Behalf Of Randy Marchany
Sent: Friday, April 21, 2006 3:22 PM
To: UNIversity Security Operations Group
Cc: marchany at candi2.cirt.vt.edu
Subject: Re: [unisog] Password policies

It's Friday and I've been reading a bunch of emails related to this
thread. I was wondering about a couple of things.

1. Account lockouts are an anachonism. They were there in the old days
sysadmins had no way to detect password enumeration attacks or the
was just plain lazy and didn't monitor the logs. I believe a DOS attack
accounts is more severe than a password enumeration attack.

<<JD>> Agreed, but why do new enumeration toolz and methodologies
continue to be posted/created if they do not work?  I don't like the
lockouts, they cause a lot of thrashing, a well monitored system and two
factor authentication seems to eliminate the need - without those
however, some of our sunset systems must have account lockouts to
prevent even educated guessing attacks!

	a. good password strength policies reduce the possibility of a 
	   successful enumeration attack. Even the dreaded password
	   feature can help here.
	b. The automated attacks we see here could lock out thousands of
	   accounts in a short period of time and do so repeatedly.
	c. Every login failure generates a record of some sort and if
	   have a syslog or eventlog scanner that monitors the logs for
	   such failures and notifies you, then you know you're under
	   and can adjust your defenses.  

<<JD>> No argument, except that in our vastly distributed systems we
don't always find folks with enough skill, time, or dedication to ensure
log/event monitoring occurs.  All too often when we test those
assertions we find folks less diligent than they asserted.

	d. If a site uses account lockouts, they have to adjust the
	   to avoid a DOS attack from impacting their operations. This
	   to defeat the purpose of the lockout.
	e. Does setting the lockout period to a short period of time
	   prevent anything? Is it smoke and mirrors?

<<JD>> For d. and e., yes, anything that is merely password related is
smoke and mirrors in my book these days, passwords cannot be depended on
in at least 6% of our systems given some of our spyware/logger
discoveries, let alone sharing and group passwording.  However, since
enumeration attacks are still working, and sunset systems cannot always
be easily patched for new password rules, you may still need to break
the continuity of a remote enumeration attack.  (Replacing an enterprise
system may take some time, time not well spent patching old, buggy, and
inadequate code - thus buffer with weaker compensating controls...)
With strong passwords this can make such an attack impractical due to
the amount of time it adds to complete the enumeration when you throw in
even a short but frequent pause.  Successes are gained when machines can
run uninterrupted at high speed.  If you insert extended breaks every
few tries, the attacks will not likely succeed.  Smoke and mirrors - too
harsh for some situations, but true regarding password rule setting in
general in my book.  A "Something You Know" security device can be
compromised and shared world-wide in seconds.  A hardware device or bio
control is very limited in how widely and how quickly it can be
compromised if well designed.  <<JD>>

2. The arguments about changing passwords frequently seem to address a 
perceived threat of a password compromise by interception (keystroke
recorder, phish, sniffer, etc.) or by post-it note. 2-factor
authentication seemingly eliminates the need for aging but does it
eliminate the DOS threat by account lockout?

<<JD>> And don't forget the simple threat of insider capture and misuse.
Admins can sniff all they want, or export SAM/PSW files for cracking,
and they know the enterprise secret shared passwords.  When an admin is
relieved of his/her duties, those enterprise secrets aren't magically
removed from his/her memory, and the SAM files sitting on his/her thumb
drive are wide open for any type of brute force analysis.  Changing
passwords "frequently enough" removes some of this risk, as a
disgruntled ex-employee can use these "procedural" weaknesses to great
advantage otherwise. I've seen several instances of individuals
"pilfering" bandwidth or pursuing "revenge" through such techniques
years after they left the institution.  Account expiry and password
changing practices could have killed these thefts and attacks.  This of
course means that those magic customer support passwords that admins
share have to be changed frequently, perhaps more so than common
customers.  Unfortunately in my experience just the opposite is true,
and something like "DilbertRulez!" remains the support password for
several generations of IT admins and support folks, for years on end.

Just wondering.  <<JD>> - I think your wondering works IF we do all the
other things right, but we seldom do, and therefore we need to
compensate, sometimes in an archaic and less than perfect manner. It's
the same problem with putting a thumb print reader on a notebook.  It
works if the drive stays in the notebook, but the drive can be easily
removed or duplicated or slaved as a second on a machine with no
thumb-drive, so physical protection (and possibly encryption) is still
needed despite a PC locking cable and thumb-reader.  <<JD>>

unisog mailing list
unisog at lists.sans.org

More information about the unisog mailing list