Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
OPIE(4)			   Kernel Interfaces Manual		       OPIE(4)

       OPIE - One-time Passwords In Everything

       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  re-
       sponse  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 au-
	      thenticate a user. In OPIE, this is a three-item group  consist-
	      ing  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 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 se-
	      cret 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  se-
	      quence 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. Un-
       fortunately, 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 go-
       ing to get them anywhere. It's important, however, to make sure you en-
       code  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	encod-
       ing 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  se-
       quence number is	always decrementing by one and that, in	the S/Key sys-
       tem, 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 se-
       quence 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 re-
       sponses.	 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 buf-
       fer 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_CHAL-
       LENGE_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  re-
       sponse 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 key-
       strokes and capture your	password even if you are running the OPIE cal-
       culator 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 key-
       strokes 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.

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


Want to link to this manual page? Use this URL:

home | help