FreeBSD 7.0 manual page repository

FreeBSD is a free computer operating system based on BSD UNIX originally. Many IT companies, like DeployIS is using it to provide an up-to-date, stable operating system.

OPIE - One-time Passwords In Everything

 

NAME

        OPIE - One-time Passwords In Everything
 

DESCRIPTION

        OPIE  is  a package derived from the Bellcore S/Key Version 1 distribu‐
        tion that helps to secure a system against replay attacks (see  below).
        It  does  so using a secure hash function and a challenge/response sys‐
        tem. It provides replacements for the login(1), su(1), and ftpd(8) pro‐
        grams 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  authen‐
        ticate  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 calcu‐
        lator 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  con‐
               sisting  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 chal‐
               lenge 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 mul‐
               tiple 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  communica‐
        tions  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 communi‐
        cated between machines in encoded or  encrypted  form,  as  long  as  a
        cracker can get in by simply replaying a previously captured communica‐
        tion, you are at risk. Up until very recently, Novell NetWare was  vul‐
        nerable  this way. A cracker couldn’t find out what your password actu‐
        ally 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
        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 conjunc‐
        tion 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  algo‐
        rithm  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.
        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  spe‐
        cific 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 decla‐
        rations, 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");
        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 secu‐
        rity 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.
        ftpd(8)  login(1),  opie(4),  opiekeys(5),  opieaccess(5),  opiekey(1),
        opieinfo(1), opiepasswd(1),
 
        Lamport, L. "Password Authentication with Insecure Communication", Com‐
        munications 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)
 

Sections

Based on BSD UNIX
FreeBSD is an advanced operating system for x86 compatible (including Pentium and Athlon), amd64 compatible (including Opteron, Athlon64, and EM64T), UltraSPARC, IA-64, PC-98 and ARM architectures. It is derived from BSD, the version of UNIX developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. Additional platforms are in various stages of development.