Re: S/Key & OPIE Database Vulnerability

[stevev () HEXADECIMAL UOREGON EDU (Steve VanDevender)]

Mudge writes:
> Given that you know what machine you are connecting to, the use of the
> seed in the S/key challenge is not as necessary to present to the end user
> as it might be otherwise.
>
> Thus - server: abc123 challenge: s/key 99 K113356
>
> could be reduced to server: abc123 challenge: s/key 99 as presented to the
> user. This would make the current dictionary attacks largely unusable as
> there is a secret that is required but unknown to the attacker.
>
> The original version of s/key that I had modified to run on the L0pht
> machine did just that (sorry folks, the software was long blown away -
> though hobbit has a niced moded version of s/key on ftp://avian.org I
> believe).
>
> If you can get to this point, then it makes all the sense in the world to
> not have the /etc/skeykeys file world readable.

Initially I thought this meant removing the seed entirely from S/Key.
Mudge clarified this to me by explaining that what he meant was removing
the routine presentation of the seed in the login challenge, but
continuing to use it internally.  It would still be necessary to present
a new seed in the process of renewing one's S/Key sequence, so while the
seed is still exposed, the amount of repeat exposure would be
significantly reduced.  This is at least quite a bit better than what I
thought he meant before.

Ultimately I wonder how much of a future S/Key has now that SSH and
similar utilities are widely deployed and provide much more
sophisticated protections, especially session encryption.