S/Key & OPIE Database Vulnerability

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

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.