Ahhh but here was my concern back in 95/96 which appears to still be valid: Given that you know what machine you are connecting to, the use of the seed in the S/key challenge is not as necessary to present to the end user as it might be otherwise. Thus - server: abc123 challenge: s/key 99 K113356 could be reduced to server: abc123 challenge: s/key 99 as presented to the user. This would make the current dictionary attacks largely unusable as there is a secret that is required but unknown to the attacker. The original version of s/key that I had modified to run on the L0pht machine did just that (sorry folks, the software was long blown away - though hobbit has a niced moded version of s/key on ftp://avian.org I believe). If you can get to this point, then it makes all the sense in the world to not have the /etc/skeykeys file world readable. The argument of, well if you can sniff the network traffic you get all of the information that you would have access to by looking at /etc/skeykeys so leave them both open doesn't wash. . local network to local network connection over a switch minimizes the amount of sniffing possible in some situations . internal to internal connections might be over a situation that does transit a compromised network There are plenty of other scenarios - is fixing one problem and not the other a partial improvement only? Yes. Can it still be beneficial in certain environments and thus not universally shunned? Yes. My recommendation is to not have the skeykeys file world readable - and if you can in a particular environment, remove the seed that goes across the network. Either one alone can still help certain situations though. just my .02 cheers, .mudge On Tue, 25 Jan 2000, Steve VanDevender wrote: > Mudge writes: > > Just as an FYI - MONkey, the S/Key cracker and a white paper talking about > > the problems with having the skeykeys file readable was released by the > > L0pht in May of 1996. > > > > The tool allows one to not only use the skeykeys file as entry to the > > crypt and compare but also the network response due to too much server > > side information being present. > > > > The tool and paper are still available > > at: http://www.l0pht.com/advisories/skey_paper_and_tool > > It doesn't surprise me that S/Key cracking software has existed for a > while, and I certainly did not mean to imply that S/Key is immune to > dictionary attacks on user secrets. > > My point was that the skeykeys/opiekeys file does not contain any > information that has not already been exposed on the network, so making > those files unreadable is not truly hiding the information they contain; > at best it only keeping attackers away from a convenient central > repository of previously exposed information. > > There are also other ways to attack S/Key secrets. Users of S/Key may > keep their secrets in a laptop or palmtop in easily readable form. If > the user keeps the secret in his head, then it's possible to > "shoulder-surf" the secret as it's typed in. Some users of S/Key may > also print out and carry lists of precomputed challenge responses if > they don't have a portable response calculator. Users who are > particularly weak on S/Key concepts may actually use one remote system > to compute S/Key responses for another and expose their secret in the > process, or keep their S/Key secret on the same system that they use > S/Key authentication on. >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:32 PDT