Dermot Tynan <dtynan @
fws .
ilo .
dec .
com> writes about obscurity:
> .... In point of fact, a lot of so-called secure
>systems are based on this principle. If you take something like
>SecurID, and their handheld time-based authentication units, if you
>knew the alogrithm and serial number involved, you could possibly
>predict the next number. I'm not saying this to generate a scare, nor
>am I singling out SecurID, but it is true of many systems that complete
>knowledge of every underlying component can reveal weaknesses of which
>even the designers are unaware.
In order to make the phrase "security through obscurity" (STO)
meaningful, we have to be careful about what's being kept obscure. I
think it's fair to say that all realistic computer security measures
that allow controlled data sharing and protection in a community of
users *must* rely on secret information. Passwords, crypto keys, the
secret half of a public key, etc. Something is kept secret.
The difference between STO and reliance on secret information is this:
If the security measures can't handle the risk of compromising the
secret information, then it's STO. For example, passwords aren't
usually STO because you can change them easily if compromise is
suspected. I'm not that familiar with SecurID, but I expect you can
get a similar effect at least by replacing a compromised card. But if
everyone shares the same password or SecurID seed value or secret key
and you can't change them in practice (a classic case from early DES
deployment by the financial industry) then it's STO. Once the secret
is disclosed, you can't fix it easily. And that's a case of good
technology being done in by poorly implemented procedures. It always
comes down to what people can do.
Rick.
smith @
sctc .
com secure computing corporation
|
|
