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

FreeBSD Manual Pages

  
 
  

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

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

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

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

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

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

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

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

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=opie&sektion=4&manpath=FreeBSD+14.3-RELEASE+and+Ports>

home | help