[114716] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Poor password management may have led to bank meltdown

daemon@ATHENA.MIT.EDU (Jon Callas)
Wed Feb 6 20:30:31 2008

Cc: cryptography@metzdowd.com
From: Jon Callas <jon@callas.org>
To: Arshad Noor <arshad.noor@strongauth.com>
In-Reply-To: <47A789C2.5070206@strongauth.com>
Date: Wed, 6 Feb 2008 13:44:20 -0800


On Feb 4, 2008, at 1:55 PM, Arshad Noor wrote:

> Do business people get it?  Do security professionals get it?
> Apparently not.
>
> Arshad Noor
> StrongAuth, Inc.
>
> Huge losses reported by Soci=E9t=E9 G=E9n=E9rale were apparently =
enabled
> by forgotten low-level IT chores such as password management.
>
> =
http://www.infoworld.com/article/08/02/04/Poor-password-management-may-hav=
e-led-to-bank-meltdown_1.html

Yes, but get what? "It" is a vague noun.

The reporter showed some wit by using the word "may."

This was an attack by an evil (or crazy) insider. Evil insider attacks =20=

are the hardest to protect against. If the insider decided that he was =20=

going to start making trades for whatever reason, then he'd find a =20
weak point that would allow him to make trades, and use it, no matter =20=

what it is. (My personal hypothesis is a variant of a mad-scientist =20
attacker -- "They laughed at me when I told them my trading theories! =20=

Laughed! But I'll show them! I'll show them ALL!!!")

If this person had worked for 1000 hours to get a hardware token, he =20
would have just done the work. The result may have been an order of =20
magnitude more. High-security procedures tend to be more brittle for =20
psychological reasons. If you have the magic dingus, then you are =20
authorized, and no one ever questions the dingus.

Also, one must look at the economics and psychology of the situation. =20=

Traders are prima-donna adrenaline junkies who trade vast sums of =20
money all the time and are not shy about expressing their =20
frustrations. Looking at the sheer economics first:

* A trader trades C units of currency every hour, with an average =20
profit of P (for example 5% profit is P=3D1.05).

* There are T traders in the organization.

* The extra authentication produces a productivity drop of D. For =20
example, let us suppose a trader has to authenticate once per hour, =20
and it takes 10 seconds to authenticate. This gives us a D of .9972 or =20=

3590/3600.

So the operational cost of your authentication is (1-D)*T*C*P per =20
hour. Divide =804.9G by that, and you get the number of hours for the =20=

raw break-even time on this.

Add to this the probability that the hassle will convince a trader to =20=

jump ship to another firm (J), times the number hours of trading lost =20=

until you find a replacement (H). We'll assume the replacement needs =20
no spinup time to become as productive as the previous trader. That's =20=

an additional cost of J*H*T*C*P. This is the psychological factor. As =20=

I said, traders are prima donnas who are used to getting their own way.

People have criticized post-9/11 airline security on similar grounds. =20=

They observe that some number of people drive rather than fly, and =20
calculate out the difference in deaths-per-passenger-mile. I've seen =20
numbers that work out to a handful of 9/11s per year caused by traffic =20=

displacement. They also observe that large numbers of people spend =20
extra time in lines, which works out to a "lost life" number. For =20
example, if you assume that passengers spend 10 extra minutes clearing =20=

security and a life is 70 years, then roughly 6 million passengers =20
represents one lost life.

There's always much to criticize in these models. I could write a =20
reply to this message with criticisms, and so can you. Nonetheless, =20
the models show that there's more than just the raw security to think =20=

about.

	Jon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post