The Joy of S/Key

by Veghead

One Time Passwords (OTP) are certainly nothing new. In fact, they have been in use for over ten years. The idea is essentially very simple: every time you login to a system, you use a different password. If someone were to eavesdrop on the connection, the password they captured would be useless to them.

In 1994, Neil Haller of Bellcore announced the “S/KEY One Time Password System” at the Symposium on Network and Distributed System Security. It described a practical way to implement OTP that was both secure and simple. Over the years it has matured into strong, practical system that is now described by RFC2289. Furthermore, implementations exist for many Operating Systems, and just about all BSD flavours include it as standard. Despite this, it is still rare, in my experience anyway, to encounter people that have even heard of it. As far as I can tell, there are two main reasons for its lack of popularity:

  1. In the days of SSH and encrypted traffic, people no longer think it's necessary.
  2. In order to login to a system using S/KEY, you need a computer to generate the next password, which raises the question of how you securely login to it.

While both points appear valid, they are both flawed.

It is true that SSH arguably does a better job of protecting passwords from eavesdroppers. In fact SSH provides for more than that, and it also protects all content from eavesdroppers. However there is one very common form of attack to which SSH is not immune: keylogging. Keyloggers record the keys you hit, and they don't care whether you're using an SSH client or telnet. They have to be installed on the machine you are using, either in software or hardware. However, now that we live in the age of Microsoft and Cybercafes, using a trojanised machine is all too easy to do. What most people don't realise is that SSH, or at least OpenSSH, is already S/KEY aware. So why not use it ?

As for the second point, indeed you do need a computer. However - you, dear reader, almost certainly have a computer in your pocket or on your wrist at this moment. In fact, if your mobile phone is Java-enabled , which these days is quite likely, then you can use it to generate S/KEY passwords. Very much like an RSA SecurID fob, only cheaper, and without a six-month lifespan.

This article gives an introduction to S/Key, together with an example of how to start using it on OpenBSD. The final section of this article lists several links to further reading, S/Key generators and details of using it on other Operating Systems.

The Guts

This section explains how S/Key actually works. Feel free to skip it if you're not interested although, in my opinion at least, it is not only interesting, but quite beautiful!

A user wishing to use OTP to login to a server must first initialise the S/Key system. The initialisation consists of a short string provided by the server, known as the seed, and a secret passphrase provided by the user. The two strings are concatenated and passed through a hash function. RFC2289 allows for the use of three different hash functions: MD4, MD5 and SHA-1. The choice of hash is left up to the user.

The output of the hash function is then reduced, or folded, to 64-bits using a method described in the RFC. This 64-bit value, known as theinitial step,is then passed through the hash function, and again folded. This process continues until the hash has been applied a number of times, let's say 99. The server then stores the final output, together with the seed value and the number of times the hash was applied, the sequence number, in the server's S/Key database. The system is now ready to accept a login.

When the user wishes to login to the server, the server provides a challenge, which consists of the chosen hash, the seed and a number which is one less than the sequence number stored in the database; in this case, 98.

The user then goes through the same procedure used to produce the initial step and hashes it that number of times. The resulting 64-bit hash is the One Time Password.

The user then conveys this password to the server (more about this later).

Remember that this is not going to be the same as the hash stored in the server's S/Key database, which has been hashed one more time. So, in order to compare it to that which is stored in the database , the server must hash the password one more time. If it matches, the user has demonstrated they know the passphrase and so they have successfully been authenticated. The server stores the password as provided by the user (i.e. before the server applied the final hash) together with the new, lower, sequence number (98) in the database and logs the user in.

The next time the user logs in, the sequence number in the challenge will be the next lowest sequence number, in this case 97.

From this we can infer:

There is one significant step in the process that has been omitted thus far. Whilst the user may legitimately type the 8 digit hex number in response to the challenge, humans are notoriously averse to this sort of thing. Consequently, RFC2289 also provides a user-friendly way of expressing the 64-bit passphrase in English. A simple algorithm is provided, together with a small lexicon, that describes a method by which any 64-bit string can be converted to a list of six words, and back again. For example, the 64-bit number:

3F3B F4B4 145F D74B

would be converted to the English words:

TAG SLOW NOV MIN WOOL KENO

For most users, this makes the whole procedure far less painless and far more acceptable.

Using S/KEY

Initially, the system needs to have S/Key enabled. The superuser merely needs to issue the command:

skeyinit -E

And the system will be available to all users.

Each user that wishes to use S/Key needs to initialise their account. The skeyinit(1) program is used for this, too. In this example we plan to use SHA1 hashes, and so the command issued is:

skeyinit -sha1

The system responds with a warning and prompts the user to enter their current system password:

Reminder
- Only use this method if you are directly connected
          or have an encrypted channel.  If you are using telnet,
          hit return now and use skeyinit -s.
Password:

If the authentication was successful, the user is then prompted for their secret passphrase. In our example the passphrase is “fred is dead”:

[Updating zaphod with sha1]
Enter secret passphrase: 
Again secret passphrase:

ID zaphod skey is otp-sha1 99 dorm23705
Next login password: MASK OMEN BOOM IRMA SMUG TORE

The account is now initialised, and skeyinit responds with the next challenge and corresponding password. You don't need to know these at this stage but it's comforting to know that everything is working.

So, let's try logging in. We ssh as normal, except we append ':skey' to the username. This tells ssh that we wish to use S/Key authentication:

$ ssh -l zaphod:skey 

The server then responds with a challenge:

otp-sha1 98 dorm23705
S/Key Password: 

So, using our favourite S/Key generator, we generate the password for this session. This simply involves supplying the generator with the challenge, which consists of the sequence number (“98”) and seed (“dorm23705”), the hash type ('SHA1'), and the secret passphrase (“fred is dead”).

How these are supplied to the generator depends entirely on generator used. For example, if you are logging in from a OpenBSD machine, you will probably use the skey(1) command line tool. In this case the command issued would be:

skey-sha1 98 dorm23705

which will then prompt you for the passphrase.

If, however, you are using vejotp, the challenge can be stored in the Java device's memory and so the most you will need to supply is the passphrase.

Whichever S/Key generator you choose, the password in this case will be:

TWIG LET IFFY DATE RON CARL

Type this at the “S/Key Password” prompt and, all being well, you're in!

The next time you wish to login, the challenge will be slightly different. The seed (“dorm23705”) will remain the same, however the sequence number will be decreased by one (“97”). You'll see that the password generated in response to this challenge will be completely different:

PAP LARK MULE DUMB FUSS WARD

If you use a BSD and are concerned about security, then this simple, brilliant system is already there for you. It is not a replacement for SSH and other forms of encrypted protocols, but it does provide additional security for a very small amount of extra effort. It also impresses the suits who, at last, have been forced to take security seriously.

<< Back to Veghead

Valid XHTML 1.0 Transitional