Re: S/Key & OPIE Database Vulnerability

[mudge () L0PHT COM (Mudge)]

Just as an FYI - MONkey, the S/Key cracker and a white paper talking about
the problems with having the skeykeys file readable was released by the
L0pht in May of 1996.

The tool allows one to not only use the skeykeys file as entry to the
crypt and compare but also the network response due to too much server
side information being present.

The tool and paper are still available
at: http://www.l0pht.com/advisories/skey_paper_and_tool

cheers,

.mudge

On Sun, 23 Jan 2000, Steve VanDevender wrote:

> This "security advisory" seems to result from a fundamental
> misunderstanding of how S/Key works.  The point of S/Key is that it is
> fully intended to work even when all the information in the skeykeys or
> opiekeys file is publicly known, and in fact all of the same information
> can be obtained merely by sniffing the network or looking over the
> shoulder of the S/Key user.
>
> Here's an example of an opiekeys line:
>
> stevev 0498 ca0693           8c979c12f4a3578e  Jul 25,1996 11:00:48
>
> Respectively the fields are the user name, the sequence number, the
> 64-bit number decoded from their most recent challenge response, and the
> date.
>
> Only the sequence number, challenge word, and 64-bit number are used in
> the S/Key algorithm.  The sequence number and challenge word are
> presented to the user in the S/Key challenge; the 64-bit number can be
> decoded trivially from from the user's six-word response.
>
> The security of S/Key depends on the privacy of the user's secret (which
> you should note is not stored in any form in the keys file), that the
> sequence of possible challenge responses is used in backwards order, and
> that the function used to generate the sequence is not feasibly
> invertible (because of the use of a cryptographic hash function to
> generate successive terms of the sequence).
>
> Since the all of a user's information kept in the skeykeys/opiekeys file
> is exposed every time the user logs in, there is no real security
> benefit to making the file unreadable.  An S/Key user who chooses an
> easily-guessed secret will still be susceptible to dictionary attack
> whether or not his public information can be obtained from the file.