[910] in WWW Security List Archive
Security testing
daemon@ATHENA.MIT.EDU (Chuck McManis)
Fri Sep 22 16:56:34 1995
Date: Fri, 22 Sep 1995 10:32:36 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: efrank@ncsa.uiuc.edu, Harald.T.Alvestrand@uninett.no
Cc: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
>Security bugs like this one CANNOT be discovered by a "black box" test;
>it would be impossible for a reasonable (?) standardized test to reverse-
>engineer the random-number generation mechanism of Netscape.
You are correct, that is why security should be tested by a vulnerability
analysis and not simply basic function tests. The idea is fairly simple to
express, you identify all of the "bad" things that can happen, in this case
someones CC# gets compromised, and then go through the conditions that have
to be true for that to be the case. You prune out the ones that don't involve
the product in anyway (for example, a complete VA of NetScape navigator
might legitimately include the fact that when you purchased your copy at the
store, the carbon copy of the receipt was made available to a crook, but
generally that level examination is reserved for nuclear weapons surety).
In this case someone would have said "guess the random number" as one way
to get the key, and then logically if you are using a PRNG then to get there
would require that you "guess the seed" and then you look at your seed
function and that would have "reconstruct the seed" and at this point
someone would say "This is a pretty easy seed to guess, maybe we should
use something else."
There is a technique and a mindset to designing secure systems, much like
there is to building operating systems or language design. Unfortunately
it doesn't get as much air time in university classes as it should.
--Chuck
