NAME
OPIE - One-time Passwords In Everything
DESCRIPTION
OPIE is a package derived from the Bellcore S/Key Version 1
distribution that helps to secure a system against replay attacks (see
below). It does so using a secure hash function and a
challenge/response system. It provides replacements for the login(1),
su(1), and ftpd(8) programs that use OPIE authentication as well as
demonstrate how a program might be adapted to use OPIE authentication.
OPIE was developed at and for the United States Naval Research
Laboratory (NRL). OPIE is derived in part from Berkeley Standard
Distribution UNIX and the Bellcore S/Key Version 1 distribution.
From the average user's perspective, OPIE is a nuisance that prevents
their account from being broken into. The first time a user wishes to
use OPIE, (s)he needs to use the opiepasswd(1) command to put an entry
for them into the OPIE database. The user can then use OPIE to
authenticate themselves with any program that supports it. If no other
clients are being used, this means they can use OPIE to telnet, rlogin,
or ftp into the system, log in on a terminal port (like a modem), or
switch to another user's account. When they would normally be asked for
a password, they will get a challenge from the server. They then need
to copy that challenge (or re-type, if they don't have the ability to
copy and paste through something like a window system) to their
calculator program, enter their password, then copy (or re-type) the
response from the calculator as their password. While this will seem
cumbersome at first, with some practice, it becomes easy.
TERMS
user name
The name that the system knows you as. For example, "jdoe".
secret password
A password, usually selected by the user, that is needed to gain
access to the system. For example, "SEc1_rt".
challenge
A packet of information output by a system when it wishes to
authenticate a user. In OPIE, this is a three-item group
consisting of a hash identifier, a sequence number, and a seed.
This information is needed by the OPIE calculator to generate a
proper response. For example, "otp-md5 95 wi14321".
response
A packet of information generated from a challenge that is used
by a system to authenticate a user. In OPIE, this is a group of
six words that is generated by the calculator given the
challenge and the secret password. For example, "PUP SOFT ROSE
BIAS FLAG END".
seed A piece of information that is used in conjunction with the
secret password and sequence number to compute the response. Its
purpose is to allow the same secret password to be used for
multiple sequences, by changing the seed, or for authentication
to multiple machines by using different seeds.
sequence number
A counter used to keep track of key iterations. In OPIE, each
time a successful response is received by the system, the
sequence number is decremented. For example, "95".
hash identifier
A piece of text that identifies the actual algorithm that needs
to be used to generate a proper response. In OPIE, the only two
valid hash identifiers are "otp-md4", which selects MD4 hashing,
and "otp-md5", which selects MD5.
REPLAY ATTACKS
When you use a network terminal program like telnet(1) or even use a
modem to log into a computer system, you need a user name and a secret
password. Anyone who can provide those to the system is recognized as
you because, in theory, only you would have your secret password.
Unfortunately, it is now easy to listen in on many computer
communications media. From modem communication to many networks, your
password is not usually safe over remote links. If a cracker can listen
in when you send your password, (s)he then has a copy of your password
that can be used at any time in the future to access your account. On
more than one occasion, major sites on the Internet have been broken
into exactly this way.
All an attacker has to do is capture your password once and then replay
it to the server when it's asked for. Even if the password is
communicated between machines in encoded or encrypted form, as long as
a cracker can get in by simply replaying a previously captured
communication, you are at risk. Up until very recently, Novell NetWare
was vulnerable this way. A cracker couldn't find out what your password
actually is, but (s)he didn't need to -- all that was necessary to get
into your account was to capture the encrypted password and send that
back to the server when asked for it.
ONE-TIME PASSWORDS
One solution to the problem of replay attacks is to keep changing the
way that a password is being encoded so that what is sent over the link
to another system can only be used once. If you can do that, then a
cracker can replay it as many times as (s)he wants -- it's just not
going to get them anywhere. It's important, however, to make sure you
encode the password in such a way that the cracker can't use the
encoded version to figure out what the password is or what a future
encoded password will be. Otherwise, while still an improvement over
no encoding or a fixed encoding, you can still be broken into.
THE S/KEY ALGORITHM
A solution to this whole problem was invented by Lamport in 1981. This
technique was implemented by Haller, Karn, and Walden at Bellcore. They
They created a free software package called "S/Key" that used an
algorithm called a cryptographic checksum. A cryptographic checksum is
a strong one-way function such that, knowing the result of such a
function, an attacker still cannot feasibly determine the input.
Further, unlike cyclic redundancy checksums (CRCs), cryptographic
checksums have few inputs that result in the same output.
In S/Key, what changes is the number of times the password is run
through the secure hash. The password is run through the secure hash
once, then the output of the hash is run through the secure hash again,
that output is run through the secure hash again, and so on until the
number of times the password has been run through the secure hash is
equal to the desired sequence number. This is much slower than just,
say, putting the sequence number in before the password and running
that through the secure hash once, but it gains you one significant
benefit. The server machine you are trying to connect to has to have
some way to determine whether the output of that whole mess is right.
If it stores it either without any encoding or with a normal encoding,
a cracker could still get at your password. But if it stores it with a
secure hash, then how does it account for the response changing every
time because the sequence number is changing? Also what if you can
never get to the machine any way that can't be listened in on? How do
you change your password without sending it over the link?
The clever solution devised by Lamport is to keep in mind that the
sequence number is always decrementing by one and that, in the S/Key
system, simply by running any response with a sequence number N through
the secure hash, you can get the response with a sequence number N+1,
but you can't go the other way. At any given time, call the sequence
number of the last valid response that the system got N+1 and the
sequence number of the response you are giving it N. If the password
that generated the response for N is the same as the one for N+1, then
you should be able to run the response for N through the secure hash
one more time, for a total of N+1 times, and get the same response as
you got back for N+1. Once you compare the two and find that they are
the same, you subtract one from N so that, now, the key for N that you
just verified becomes the new key for N+1 that you can store away to
use the next time you need to verify a key. This also means that if you
need to change your password but don't have a secure way to access your
machine, all the system really needs to have to verify your password is
a valid response for one more than the sequence number you want to
start with.
Just for good measure, each side of all of this uses a seed in
conjunction with your password when it actually generates and verifies
the responses. This helps to jumble things up a little bit more, just
in case. Otherwise, someone with a lot of time and disk space on their
hands could generate all the responses for a lot of frequent passwords
and defeat the system.
This is not, by any means, the best explanation of how the S/Key
algorithm works or some of the more minor details. For that, you should
go to some of the papers now published on the topic. It is simply a
quick-and-dirty introduction to what's going on under the hood.
OPIE COMPONENTS
Included in the OPIE distribution are three OPIE client programs:
opielogin(1), opiesu(1), and opieftpd(8). These three programs are
modified versions of the freely available 4.3BSD Net/2 versions of
login(1), su(1), and ftpd(8), respectively. Although most of the
modifications actually done to them are so that they will work on as
many machines as possible, they also have been modified to support OPIE
for authentication. As you will see from the source, it is not very
difficult to add support for OPIE to other programs.
There are also three programs in the OPIE distribution that are
specific to the OPIE system: opiepasswd(1), which allows a user to set
and change their OPIE password, opieinfo(1), which allows a user to
find out what their current sequence number and seed are, and
opiekey(1), which is an OPIE key calculator.
Adding OPIE authentication to programs other than the ones included as
clients in the OPIE distribution isn't very difficult. First, you will
need to make sure that the program includes <stdio.h> somewhere. Then,
below the other includes such as <stdio.h>, but before variable
declarations, you need to include "opie.h". You need to add a variable
of type "struct opie" to your program, you need to make sure that the
buffer that you use to get a password from the user is big enough to
hold OPIE_RESPONSE_MAX+1 characters, and you need to have a buffer in
which to store the challenge string that is big enough to hold
OPIE_PROMPT_MAX+1 characters.
When you are ready to output the challenge string and know the user's
name, you would use a call to opiechallenge. Later, to verify the
response received, you would use a call to opieverify. For example:
#include <stdio.h>
.
.
#include "opie.h"
.
.
char *user_name;
/* Always remember the trailing null! */
char password[OPIE_RESPONSE_MAX+1];
.
.
struct opie opiedata;
char opieprompt[OPIE_PROMPT_MAX+1];
.
.
opiechallenge(&opiedata, user_name, &opieprompt);
.
.
if (opieverify(&opiedata, password)) {
printf("Login incorrect");
TERMINAL SECURITY AND OPIE
When using OPIE, you need to be careful not to allow your password to
be communicated over an insecure channel where someone might be able to
listen in and capture it. OPIE can protect you against people who might
get your password from snooping on the line, but only if you make sure
that the password itself never gets sent over the line. The important
thing is to always run the OPIE calculator on whichever machine you are
actually using - never on a machine you are connected to by network or
by dialup.
You need to be careful about the X Window System, because it changes
things quite a bit. For instance, if you run an xterm (or your favorite
equivalent) on another machine and display it on your machine, you
should not run an OPIE calculator in that window. When you type in your
secret password, it still gets transmitted over the network to go to
the machine the xterm is running on. People with machines such as X
terminals that can only run the calculator over the network are in an
especially precarious position because they really have no choice.
Also, with the X Window System, as with some other window system (NeWS
as an example), it is sometimes possible for people to read your
keystrokes and capture your password even if you are running the OPIE
calculator on your local machine. You should always use the best
security mechanism available on your system to protect your X server,
be it XDM-AUTHORIZATION-1, XDM-MAGIC-COOKIE-1, or host access control.
*Never* just allow any machine to connect to your server because, by
doing so, you are allowing any machine to read any of your windows or
your keystrokes without you knowing it.
SEE ALSO
opie(4), opiekeys(5), opieaccess(5), opiekey(1), opieinfo(1),
opiepasswd(1), opielogin(1), opieftpd(8)
Lamport, L. "Password Authentication with Insecure Communication",
Communications of the ACM 24.11 (November 1981), pp. 770-772.
Haller, N. "The S/KEY One-Time Password System", Proceedings of the
ISOC Symposium on Network and Distributed System Security, February
1994, San Diego, CA.
Haller, N. and Atkinson, R, "On Internet Authentication", RFC-1704, DDN
Network Information Center, October 1994.
Rivest, R. "The MD5 Message Digest Algorithm", RFC-1321, DDN Network
Information Center, April 1992.
Rivest, R. "The MD4 Message Digest Algorithm", RFC-1320, DDN Network
Information Center, April 1992.
AUTHOR
Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S.
Walden of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan
McDonald, and Craig Metz.
S/Key is a trademark of Bell Communications Research (Bellcore). UNIX
is a trademark of X/Open.
CONTACT
OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join,
send an email request to:
skey-users-request@thumper.bellcore.com
January 10, 1995