[13554] in bugtraq
Re: S/Key & OPIE Database Vulnerability
daemon@ATHENA.MIT.EDU (Evil Pete)
Tue Jan 25 13:54:32 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <16883.948768443.1@kizmiaz.dis.org>
Message-Id: <200001250247.SAA16887@kizmiaz.dis.org>
Date: Mon, 24 Jan 2000 18:47:24 -0800
Reply-To: Evil Pete <shipley@DIS.ORG>
From: Evil Pete <shipley@DIS.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of Sun, 23 Jan 2000 18:23:41 -0800.
<14475.47021.159106.342836@hexadecimal.uoregon.edu>
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.
