RE: Stanford break in

["Paul D. Robertson" <paul () compuwar net>]

On Fri, 23 Apr 2004, Melson, Paul wrote:

> The problem is that precomputational guessing attacks like RainbowCrack
> for NTLM and AsLeap for Cisco LEAP have cut the amount of actual time
> necessary to calculate a password from its ciphertext to a minute
> fraction of what previous dictionary or brute-force attacks required.
> And though you can use an unseemly password policy to make these attacks
> difficult now, storage and processing capacity will continue to become
> greater and cheaper.  However, I don't expect that we'll start adding
> more characters to our keyboards at a rate that can keep up.

That's one of the reasons that I think password length and character games
aren't worth the pain- I'm not sure they reduce risk all that much
considering the support costs (it'd be interesting to trend "forgotten"
passwords with weather patterns, holidays and weekends in large
organizations!)

There are two different things that I think we tend to use password
systems for (a) separating physically present users, and (b) separating
legitimate users from attackers.  To me, (a) seems to be the best use of
passwords, and (b) really needs to be all about access to the
authentication method, rather than the method itself.

Vin's reminder that regulation requires stronger authentication is a good
one, though I'm not sure the regulation provides all that much risk
reduction over good control of the access mechanism.  I've seen tokens
taped on monitors with the PIN sticked to them.

Stopping user 1 from logging in to user 2's account is solved by
non-obvious, but trivial passwords and a change timeframe.  Harder
passwords encourage writing/sharing and stop (a) and on-site (b) from
being protected against effectively.  But then exposed systems that don't
do enough reporting are dictionary attackable for (b) and that's where
"strong" passwords can help, unless the attacker has access to the hashes,
or the input vector (such as keyboard logging.)  Both cases shouldn't
intersect if architecture is done well, other than in edge cases- but
single sign-on breaks that assumption.


Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards