Re: Minimum password requirements

["Steve" <securityfocus () delahunty com>]

We can discuss/argue all day long, but if you don't age passwords then you
will fail almost any IT portion of an audit from an independent auditing
organization.

Real world example, a few departed employees had not been disabled in our
domain, their accounts were automatically disabled.  The auditors had no
issues with that.


----- Original Message ----- 
From: <dmargoli () stwing org>
To: <security-basics () securityfocus com>
Sent: Wednesday, July 21, 2004 3:25 PM
Subject: Re: Minimum password requirements


Hamish Stanaway wrote:

> Hi there Robert,
>
> I believe the reason for changing the password even though it has still
> not been hacked is a preventitive measure. For example, if I was a
> cracker hacking your network, and your password was "dddd", and once a
> month I went in sequence e.g. aaaa first month, "bbbb" second month and
> so on, within four months I would have cracked your account. This is
> called the "brute force method", and this rule reduces the chances of
> someone brute forcing an account.
> Sure, you can make a big long complex password, but it will never be
> safe from someone that is really dedicated to brute forcing your
> account, unless you have a policy set to change it x number of days, or
> monitor failed logins very closely (believe me, on big corporate
> networks this is a fuill-time job).

I've seen a couple of these posts, and I already replied before saying I
thought this was unnecessary, so I'm not trying to pick on you
specifically. But can someone please give me a real-world example where
changing passwords routinely has had any measurable benefit (yes, I know
it may be impossible to show examples of stopped intrusion attempts--but
even coming up with a realistic hypothetical that does not involve an
attacker who bruteforces at a rate of one password a month is difficult)?

In this example you give above, the attacker could just as well happen
upon your password first--assuming it takes 4 months to try every
password, his average  time to success will be half that (two months);
even if you make your timeout two months, 25% of the time he'll get it
in 1.

Now let's think about this from a more accurate perspective. Assuming an
attacker randomly tries passwords (the chances of him brute-forcing
*every single possible password* in linear order are minimal; assuming 8
character passwords guessed at 1 per second, we're talking years here),
changing the password does not significantly help your chances. The
benefit here is by whether he can guess with replacement or without (as
in, should he guess another random password, or a random password that
he hasn't already guessed--can he narrow his guessing set?). So 8
character alphanumeric, caps and lower, gives us 218340105584896
possible passwords. At one per second, over a 30 day period, going
non-stop (and if your logs don't catch *this*, you should think twice),
he guesses 2592000 passwords. So if he's allowed to assume no guessing
the same password twice--i.e. that you don't cycle your passwords
regularly--he can better his odds from 1/218340105584896 to
1/218340102992896. Not a significant change. In fact, so insignificant
that if *I* were the attacker, I wouldn't bother keeping track of
passwords I'd guessed. So does this make you safer against brute
forcing? Perhaps a very small amount.

Now, the majority of intrusions: brute forces? Dictionary attacks?
Exploit of known vulnerabilities? Or insider jobs? The last three are
serious concerns; the first, in my opinion, is not nearly as much so.
Brute forcing is deterrable with authorized log-in domains (allow
customers to log in only from their domains), failed-timouts, effective
logging (not to hard to notice thousands of failed attempts; letting a
single or two failures slip by is perfectly excusable), but perhaps
never will be stopped. Big deal.

Yet if we force users to change their passwords all the time, they'll
likely write them down on post-its, or some other place, making them
easily found by a coworker or anyone else in the area. They'll also be
frustrated and forget it a lot, increasing our workload in making us
reset their passwords often. And they won't be as productive using our
systems, which, really, defeats the whole purpose of those systems.

Weak passwords are a serious problem, I agree. But when choosing your
battles, timeout policies just aren't worth the effort to you, to your
users, or to anyone else.


---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field
pen testing experience in our state of the art hacking lab. Master the
skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------



---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off 
any course! All of our class sizes are guaranteed to be 10 students or less 
to facilitate one-on-one interaction with one of our expert instructors. 
Attend a course taught by an expert instructor with years of in-the-field 
pen testing experience in our state of the art hacking lab. Master the skills 
of an Ethical Hacker to better assess the security of your organization. 
Visit us at: 
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------