Vulnerabilities in the S/KEY one time password system

Author: Mudge
Organization: L0pht Heavy Industries (aka

This may be redistributed as long as proper credit is maintained. In other words... if you like it don't try to take credit for it. If you don't like it don't take credit for it.
This paper is still under revision and modification. If you have any comments or feedback please e-mail me.


[note: This is not intended to be an extensive introduction on how to use the s/key package. For this there are several good resources available on the net. What this paper attempts to do is to quickly summarize what some of s/key's vulnerabilities are.]

Being sniffed is the sys-admin / security specialists worst nightmare. For those that aren't privy, sniffing is slang for placing a network card into promiscuous mode so that it actually looks at all of the traffic coming along the line and not just the packets that are addressed to it. By doing this one can catch passwords, login names, confidential information, etc. Of course there are good sides to being able to place a card into promiscuous mode such as traffic analysis, debugging drivers and network applications, and testing router configurations to name just a few. In promiscuous mode anything that goes by in plaintext is fair game. Each time you telnet to a machine, ftp to another machine, connect to the smtp port or POP port, read news, off of a different machine, or issue Remote Procedure Calls you hand your password and other private information to anyone who wants to sit on the lines and listen in. There are several ways of protecting oneself. DESLogin provides completely encrypted telnet sessions, there is a kerberized POP server available, and there are hardware and software utilities to do encryption on different OSI layers. Many of these suffer from either being commercial products or simply being too difficult to administer.

A wonderful security tool was presented to the network community that provides a seeming solution to having your password sniffed. The theory behind it is to never use the same password. This is accomplished by a challenge response system. The system you are contacting issues you a unique challenge. You go off and compute your response and then send back that unique response to the host. The next time you are presented with a different challenge and thus come back with a different response. Sounds great doesn't it? What's even better is that the software for the server side and the client side are free and widely available. Here's an example of what it looks like:> telnet
Trying Connected to
Escape character is '^]'.

login: jdoe
s/key 99 k113355

What has happened here is a telnet to a machine where S/KEY is in use. After logging in with the username of jdoe, a challenge is issued. jdoe computes his response on a local machine and uses that as input for the password prompt. Let's take a look at this and figure:

s/key 99 k113355
s/key - text so the user knows what is going on.
99 - number of iterations through MD4
k113355 - seed
Assuming jdoe provided a valid response, the next time he would try to log in the iterations counter would be decremented [i.e. s/key 98 k113355] and the response that would be computed would be different. Thus anybody who sniffed the above [i.e. user: jdoe - Password: WELD GUY CHIMP SWING GONE] would not be able to gain access to the machine with this information as the password is no longer valid.

Dictionary Attacks


One of the first vulnerabilities is that all of the information is broadcast in plaintext. What this means is that it is trivial to take the challenge and response and compare this with the result of the challenge applied to words out of a dictionary.

username: jdoe
challenge: 99 k113355
jdoe's real password: ????

dictionary word 1: love
challenge: 99 k113355
(well that's not it...)

dictionary word 2: sex
challenge: 99 k113355
(not it either...)

dictionary word 3: secret
challenge 99 k113355
(bingo! )

We now know that jdoe's real password is 'secret'. With this information we can generate a valid response no matter what the challenge.

This is particularly important since in the current implementations of the skey package neither the client or server side does any sort of sanity check on the security of the chosen password. This means there is no failsafe to try to prevent you from choosing your login name as your password or other silliness.


Another source for dictionary attacks come from the /etc/skeykeys file. The number of sites that have skey set up that have the improper permissions set on this file is quite surprising. This file should not be set to world readable. While the 'keyinfo' program would like it to be so, the harm outweighs the good. The skeykeys file looks like this:

root 0072 k113357          12afaa8be65f0502  Jun 29,1995 12:40:48
jdoe 0099 k113355	c7f42dfd84914af3  May 30,1995 16:20:19

What we have here is the username, iteration counter, seed, and a hex representation of the five word response we saw before. The other three fields are simply date and time information which isn't of much interest right now. The exact same sort of dictionary hack can be made with this information. Just to bring the point home, let's pretend you have a large user base of say, 200 users, and since you are security conscious you have a shadow password system and are using s/key. While the average account will not be able to look at the real password file since it is shadowed they will not be able to do a standard dictionary attack on it. They will, however, be able to see the skeykeys file and do a dictionary attack on it if the permissions are set improperly, thus defeating the benefits of a shadowed password file.

Spoofing Attacks


Since the iteration counter is transmitted along with the seed, one possibility is to masquerade as the server. This could be done by setting up a bogus gateway or whatever. Who we are really spoofing is the user. Let's take the following scenario...

login: jdoe
[jdoe telnet's to his machine]

s/key 55 k113355
[what jdoe should have seen was a challenge of 98 k113355 but instead we have sent a lower challenge of 55 k113355.]

[jdoe calculates the response for 55 k113355 based upon his secret password]

Login incorrect
[we tell jdoe that his login was incorrect and forward the rest of the connection to the actual machine he really wanted to talk to in the first place]

With the response we have for the 55 k113355 challenge all we have to do is run it through more iterations of md4 for the subsequent responses. For example, with the information we have now, if we want to figure out the response for the challenge 60 k113355 we need to run it through 5 more iterations of md4. If we were looking for the response to the challenge of 97 k113355 we would need to run it through 42 more iterations of md4. etc. etc.

We can now telnet to the machine and, as long as the iteration counter in the challenge is above 55 k113355, we can compute the proper response without ever having to know the secret password.

There are many variations on the above theme...

Trojan Attacks


This is not a problem with s/key but simply a reminder.

The same vulnerability for trojanized login and su programs for the s/key replacements exists as the regulars.

Race Attacks


There seems to be a problem with s/key that allows two simultaneous logins to occur with the same key. If I am in a position to capture-look at-modify jdoe's responses as they go bye (i.e. we're a bogus gateway or something again), we can open up another telnet session to the same machine and, since he hasn't logged in yet the iteration counter hasn't been decremented, get the same challenge. As we receive jdoe's response we simply send the same information over to our other processes as well as his original login. With a little luck a locking problem will occur with the skeykeys file and we will both be let in under the same challenge and response. This should be easily fixable in the source but I have not yet investigated this fully.

Hi-Jacking Attacks


This is not a problem with s/key but simply a reminder.

Remember that once a connection has been established and jdoe has successfully answered the challenge with the appropriate response there are no more checks done on the s/key side of things. It is not designed to. It is not kerberos. People are too often lulled into false senses of security, as in the choosing of easily guessed passwords, when they use the s/key system. Once in, the same IP Hi-jacking and monitoring tricks can be used on jdoe's session as can be used on non-s/key sessions.


I like s/key. I think s/key is a very good utility and a great asset to the community in general. This paper should not dissuade anyone from using s/key. It is simply meant to point out certain vulnerabilities. The worst thing that can happen to a the security conscious is a false sense of security. While s/key does provide added security, neither it nor any other product currently out on the market is the be-all end-all to security. If this paper has helped to remind anyone of this then it has done it's job.