At 02:41 PM 11/21/95 +0000, Dermot Tynan wrote:
>based on one of the weaker defences. My point, yet again, is that this
>information is withheld and as such could come under the general
>category of "Security Through Obscurity". It is in no way an
>indictment of SecurID, or even an attempt at saying it can be broken.
>I picked SecurID because it was the first one that came to mind.
>
My guess is the algorithm is witheld not for STO, but as a trade secret that
they
will share under non-disclosure.
I do not consider SecurID as STO - it is a cryptographically secured system.
That said, *any* crypto system will be compromised if the keys are known, so
in that sense, yes, there is an obscurity factor in the relative
"un-guessability"
of the keys.
When I hear the phrase "security through obscurity" I think more along the lines
of these two scenarios:
A) Sysadmin A redefines his Unix "login: / password " prompt to *look* like
it's
issuing an S/Key challenge, but in reality still uses re-usable passwords.
B) Sysadmin B implements S/Key for real.
Sysadmin A is practicing STO, Sysadmin B is not. One simply "obscures"
what's really
going on, the other is based on mathematically/cryptographically sound
principles.
Personally, I'd favor Sysadmin C, who implements S/Key, SecurID, or similar
on a Unix
box, but makes it look like the standard Username/password for a VMS system. :-)
---
Stephen Goldstein steveg @
cseic .
saic .
com
My first computer: A 24K Atari 800, Rev. A ROMS, November 1980
Disclaimer: That's not what I said.
|
|
