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