opie

OPIE(4)                     Kernel Interfaces Manual                     OPIE(4)



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
       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
       The OPIE distribution has been incorporated into three standard client
       programs: login(1), su(1), and ftpd(8),

       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 TO OTHER PROGRAMS
       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_CHALLENGE_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_CHALLENGE_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
       ftpd(8) login(1), opie(4), opiekeys(5), opieaccess(5), opiekey(1),
       opieinfo(1), opiepasswd(1),

       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                         OPIE(4)