[13573] in bugtraq
Re: S/Key & OPIE Database Vulnerability
daemon@ATHENA.MIT.EDU (Mudge)
Wed Jan 26 13:48:02 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSO.4.21.0001251609270.26757-100000@0nus.l0pht.com>
Date: Tue, 25 Jan 2000 16:11:46 -0500
Reply-To: Mudge <mudge@L0PHT.COM>
From: Mudge <mudge@L0PHT.COM>
X-To: Steve VanDevender <stevev@hexadecimal.uoregon.edu>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <14478.4795.166871.553168@hexadecimal.uoregon.edu>
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.
>
