Re: S/Key & OPIE Database Vulnerability

[shipley () DIS ORG (Evil Pete)]

I disagree, by reading the skeykeys/opiekeys file you can gain
insight on all users.  While, as you point out, this can be obtained
via login probes, the skey-login program will provide false data as well.

 eg:
        fbsd#  telnet www.dis.org
        Trying 216.240.45.60...
        Connected to kizmiaz.dis.org.
        Escape character is '^]'.

        login: fooberry

        S/Key MD5 65 fd681a7be2a92421
        S/Key Password:

thus an advantage to keeping this data a system secret.

In addition by viewing the skeykeys file you can also learn more about
account usage  (last skey login etc..) which can be useful in compromising
a system while avoiding detection.

Also, in the relm of security you do not want to expose any system information
unless it is necessary. thus (imo) /etc/*.conf should not be publicly readable
unless required by the service.   All system information should be on a
"need to know basis"

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