Re: S/Key & OPIE Database Vulnerability

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

Mudge writes:
> Ahhh but here was my concern back in 95/96 which appears to still be
> valid:
>
> 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 point of having the seed (or challenge word, as I referred to it
previously) in the challenge is that when the sequence number in the
challenge becomes low, one can start a new sequence using a different
seed without the user having to change his S/Key secret.  The rationale
is quite clearly described in the RFC.  The seed is not anything like a
secret and was never intended to identify the server being connected to,
and removing it is not beneficial to the S/Key protocol.  Removing the
seed does not make dictionary attacks on the user's secret harder, let
alone "largely unusable".  At best it might force the user to choose
different secrets once in a while to restart their sequences, but if the
user is already inclined to use poor secrets, it's still not improving
security significantly.

Ultimately the security of S/Key depends on whether the user's secret
remains secret.  The choice of a good secret that is not susceptible to
a dictionary attack, then defending the secret against exposure, is the
only real way to ensure S/Key's security.