Re: S/Key & OPIE Database Vulnerability

[mudge () L0PHT COM (Mudge)]

Theoretically I agree whole heartedly.

In practice we were engaged in an audit and would not have been succesful
without the seed (I appologize for my terminology but I look at the
decrementing counter as the counter and the fixed value for the iterations
as the seed here).

People need to learn from both the theoretical and the practical - neither
work in a vacuum.

cheers,

.mudge

On Tue, 25 Jan 2000, Steve VanDevender wrote:

> 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.