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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:04 PDT