Man Linux: Main Page and Category List


       OPIE - One-time Passwords In Everything


       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.


       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".

              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".

              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.


       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 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.


       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.


       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");


       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.


       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.


       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.


       OPIE is discussed on the Bellcore "S/Key Users" mailing list. To  join,
       send an email request to:

                               January 10, 1995