gdb - Local mods (compile)
[dragonfly.git] / contrib / opie / opie.4
1 .\" opie.4: Overview of the OPIE software.
2 .\"
3 .\" %%% portions-copyright-cmetz-96
4 .\" Portions of this software are Copyright 1996-1999 by Craig Metz, All Rights
5 .\" Reserved. The Inner Net License Version 2 applies to these portions of
6 .\" the software.
7 .\" You should have received a copy of the license with this software. If
8 .\" you didn't get a copy, you may request one from <license@inner.net>.
9 .\"
10 .\" Portions of this software are Copyright 1995 by Randall Atkinson and Dan
11 .\" McDonald, All Rights Reserved. All Rights under this copyright are assigned
12 .\" to the U.S. Naval Research Laboratory (NRL). The NRL Copyright Notice and
13 .\" License Agreement applies to this software.
14 .\"
15 .\"     History:
16 .\"
17 .\"     Modified by cmetz for OPIE 2.4. Spelling fixes.
18 .\"     Modified by cmetz for OPIE 2.2. Removed MJR DES documentation. Removed
19 .\"         references to the old square brackets challenge delimiters.
20 .\"     Modified at NRL for OPIE 2.01. Updated UNIX trademark credit.
21 .\"     Definition of "seed" written by Neil Haller of Bellcore
22 .\"     Written at NRL for OPIE 2.0.
23 .\"
24 .\"     $FreeBSD: head/contrib/opie/opie.4 92914 2002-03-21 23:42:52Z markm $
25 .\"
26 .TH OPIE 4 "January 10, 1995"
27 .SH NAME
28 .B OPIE \- One-time Passwords In Everything
29 .SH DESCRIPTION
30 .LP
31 OPIE is a package derived from the Bellcore S/Key Version 1 distribution
32 that helps to secure a system against replay attacks (see below). It does so
33 using a secure hash function and a challenge/response system. It provides
34 replacements for the 
35 .IR login (1),
36 .IR su (1), 
37 and 
38 .IR ftpd (8) 
39 programs that use OPIE
40 authentication as well as demonstrate how a program might be adapted to use
41 OPIE authentication. OPIE was developed at and for the United States Naval
42 Research Laboratory (NRL). OPIE is derived in part from Berkeley Standard
43 Distribution UNIX and the Bellcore S/Key Version 1 distribution.
44 .LP
45 From the average user's perspective, OPIE is a nuisance that prevents their
46 account from being broken into. The first time a user wishes to use OPIE,
47 (s)he needs to use the 
48 .IR opiepasswd (1) 
49 command to put an entry for them into
50 the OPIE database. The user can then use OPIE to authenticate themselves
51 with any program that supports it. If no other clients are being used,
52 this means they can use OPIE to 
53 .I telnet,
54 .I rlogin, 
55 or 
56 .I ftp
57 into the system,
58 log in on a terminal port (like a modem), or switch to another user's
59 account. When they would normally be asked for a password, they will get
60 a challenge from the server. They then need to copy that challenge (or
61 re-type, if they don't have the ability to copy and paste through something
62 like a window system) to their calculator program, enter their password,
63 then copy (or re-type) the response from the calculator as their password.
64 While this will seem cumbersome at first, with some practice, it becomes
65 easy.
66
67 .SH TERMS
68 .TP 
69 .I user name
70 The name that the system knows you as. For example, "jdoe".
71 .TP
72 .I secret password
73 A password, usually selected by the user, that is needed to gain access to the 
74 system. For example, "SEc1_rt".
75 .TP
76 .I challenge
77 A packet of information output by a system when it wishes to authenticate a 
78 user. In OPIE, this is a three-item group consisting of a hash identifier,
79 a sequence number, and a seed. This 
80 information is needed by the OPIE calculator to generate a proper response. 
81 For example, "otp-md5 95 wi14321".
82 .TP
83 .I response
84 A packet of information generated from a challenge that is used by a system to 
85 authenticate a user. In OPIE, this is a group of six words that is generated by
86 the calculator given the challenge and the secret password. For example, 
87 "PUP SOFT ROSE BIAS FLAG END".
88 .TP
89 .I seed
90 A piece of information that is used in conjunction with the secret password
91 and sequence number to compute the response. Its purpose is to allow the same
92 secret password to be used for multiple sequences, by changing the seed, or
93 for authentication to multiple machines by using different seeds.
94 .TP
95 .I sequence number
96 A counter used to keep track of key iterations. In OPIE, each time a successful
97 response is received by the system, the sequence number is decremented. For 
98 example, "95".
99 .TP
100 .I hash identifier
101 A piece of text that identifies the actual algorithm that needs to be used to 
102 generate a proper response. In OPIE, the only two valid hash identifiers are 
103 "otp-md4", which selects MD4 hashing, and "otp-md5", which selects MD5.
104
105 .SH REPLAY ATTACKS
106 When you use a network terminal program like 
107 .IR telnet (1)
108 or even use a modem to log into a
109 computer system, you need a user name and a secret password. Anyone who can 
110 provide those to the system is recognized as you because, in theory, only you 
111 would have your secret password. Unfortunately, it is now easy to listen in
112 on many computer communications media. From modem communication to many 
113 networks, your password is not usually safe over remote links. If a
114 cracker can listen in when you send your password, (s)he then has a copy
115 of your password that can be used at any time in the future to access your
116 account. On more than one occasion, major sites on the Internet have been
117 broken into exactly this way. 
118 .LP
119 All an attacker has to
120 do is capture your password once and then replay it to the server when it's
121 asked for. Even if the password is communicated between machines in encoded
122 or encrypted form, as long as a cracker can get in by simply replaying
123 a previously captured communication, you are at risk. Up until very recently,
124 Novell NetWare was vulnerable this way. A cracker couldn't find out what your
125 password actually is, but (s)he didn't need to -- all that was necessary to
126 get into your account was to capture the encrypted password and send that
127 back to the server when asked for it.
128
129 .SH ONE-TIME PASSWORDS
130 One solution to the problem of replay attacks
131 is to keep changing the way that a password is being encoded so that what is
132 sent over the link to another system can only be used once. If you can do that,
133 then a cracker can replay it as many times as (s)he wants -- it's just not
134 going to get them anywhere. It's important, however, to make sure you encode
135 the password in such a way that the cracker can't use the encoded version to
136 figure out what the password is or what a future encoded password will be.
137 Otherwise, while still an improvement over no encoding or a fixed encoding,
138 you can still be broken into. 
139
140 .SH THE S/KEY ALGORITHM
141
142 A solution to this whole problem was invented by Lamport in 1981. This
143 technique was implemented by Haller, Karn, and Walden at Bellcore. They
144 created a free software package called "S/Key" that used an algorithm
145 called a cryptographic checksum. A cryptographic checksum is a strong one-way
146 function such that, knowing the result of such a function, an attacker still
147 cannot feasibly determine the input. Further, unlike cyclic redundancy
148 checksums (CRCs), cryptographic checksums have few inputs that result in the
149 same output.
150 .LP
151 In S/Key, what changes is the number of
152 times the password is run through the secure hash. The password is run through
153 the secure hash once, then the output of the hash is run through the secure
154 hash again, that output is run through the secure hash again, and so on until
155 the number of times the password has been run through the secure hash is equal 
156 to the desired sequence number. This is much slower than just, say, putting
157 the sequence number in before the password and running that through the secure
158 hash once, but it gains you one significant benefit. The server machine you
159 are trying to connect to has to have some way to determine whether the output
160 of that whole mess is right. If it stores it either without any encoding or
161 with a normal encoding, a cracker could still get at your password. But if it
162 stores it with a secure hash, then how does it account for the response 
163 changing every time because the sequence number is changing? Also what if you 
164 can never get to the machine any way that can't be listened in on? How do you
165 change your password without sending it over the link?
166 .LP
167 The clever solution
168 devised by Lamport is to keep in mind that the sequence number is
169 always decrementing by one and that, in the S/Key system, simply by running any
170 response with a sequence number N through the secure hash, you can get the
171 response with a sequence number N+1, but you can't go the other way. At any
172 given time, call the sequence number of the last valid response that the 
173 system got N+1 and the sequence number of the response you are giving it N.
174 If the password that generated the response for N is the same as the one for
175 N+1, then you should be able to run the response for N through the secure hash
176 one more time, for a total of N+1 times, and get the same response as you got
177 back for N+1. Once you compare the two and find that they are the same, you
178 subtract one from N so that, now, the key for N that you just verified becomes
179 the new key for N+1 that you can store away to use the next time you need to
180 verify a key. This also means that if you need to change your password but
181 don't have a secure way to access your machine, all the system really needs to
182 have to verify your password is a valid response for one more than the sequence
183 number you want to start with.
184 .LP
185 Just for good measure, each side of
186 all of this uses a seed in conjunction with your password when it actually 
187 generates and verifies the responses. This helps to jumble things up a little
188 bit more, just in case. Otherwise, someone with a lot of time and disk space
189 on their hands could generate all the responses for a lot of frequent passwords
190 and defeat the system.
191 .LP
192 This is not, by any means, the best explanation of how the S/Key algorithm
193 works or some of the more minor details. For that, you should go to some of
194 the papers now published on the topic. It is simply a quick-and-dirty
195 introduction to what's going on under the hood.
196
197 .SH OPIE COMPONENTS
198
199 The OPIE distribution has been incorporated into three standard client
200 programs:
201 .IR login (1), 
202 .IR su (1), 
203 and 
204 .IR ftpd (8),
205 .LP
206 There are also three programs in the OPIE distribution that are specific to
207 the OPIE system: 
208 .IR opiepasswd (1),
209 which allows a user to set and change their
210 OPIE password, 
211 .IR opieinfo (1),
212 which allows a user to find out what their current
213 sequence number and seed are, and 
214 .IR opiekey(1),
215 which is an OPIE key calculator.
216
217 .SH ADDING OPIE TO OTHER PROGRAMS
218
219 Adding OPIE authentication to programs other than the ones included as clients
220 in the OPIE distribution isn't very difficult. First, you will need to make
221 sure that the program includes <stdio.h> somewhere. Then, below the other
222 includes such as <stdio.h>, but before variable declarations, you need to
223 include <opie.h>. You need to add a variable of type "struct opie" to your
224 program, you need to make sure that the buffer that you use to get a password
225 from the user is big enough to hold OPIE_RESPONSE_MAX+1 characters, and you
226 need to have a buffer in which to store the challenge string that is big enough
227 to hold OPIE_CHALLENGE_MAX+1 characters.
228 .LP
229 When you are ready to output the challenge string and know the user's name,
230 you would use a call to opiechallenge. Later, to verify the response received,
231 you would use a call to opieverify. For example:
232 .sp 0
233
234 .sp 0
235         #include <stdio.h>
236 .sp 0
237                 .
238 .sp 0
239                 .
240 .sp 0
241         #include <opie.h>
242 .sp 0
243                 .
244 .sp 0
245                 .
246 .sp 0
247         char *user_name;
248 .sp 0
249         /* Always remember the trailing null! */
250 .sp 0
251         char password[OPIE_RESPONSE_MAX+1];
252 .sp 0
253                 .
254 .sp 0
255                 .
256 .sp 0
257         struct opie opiedata;
258 .sp 0
259         char opieprompt[OPIE_CHALLENGE_MAX+1];
260 .sp 0
261                 .
262 .sp 0
263                 .
264 .sp 0
265         opiechallenge(&opiedata, user_name, opieprompt);
266 .sp 0
267                 .
268 .sp 0
269                 .
270 .sp 0
271         if (opieverify(&opiedata, password)) {
272 .sp 0
273                 printf("Login incorrect");
274 .sp 0
275 .SH TERMINAL SECURITY AND OPIE
276
277 When using OPIE, you need to be careful not to allow your password to be
278 communicated over an insecure channel where someone might be able to listen
279 in and capture it. OPIE can protect you against people who might get your
280 password from snooping on the line, but only if you make sure that the password
281 itself never gets sent over the line. The important thing is to always run the
282 OPIE calculator on whichever machine you are actually using - never on a machine
283 you are connected to by network or by dialup. 
284 .LP
285 You need to be careful about the
286 X Window System, because it changes things quite a bit. For instance, if you
287 run an xterm (or your favorite equivalent) on another machine and display it
288 on your machine, you should not run an OPIE calculator in that window. When you
289 type in your secret password, it still gets transmitted over the network to go
290 to the machine the xterm is running on. People with machines such as
291 X terminals that can only run the calculator over the network are in an
292 especially precarious position because they really have no choice. Also, with
293 the X Window System, as with some other window system (NeWS as an example),
294 it is sometimes possible for people to read your keystrokes and capture your
295 password even if you are running the OPIE calculator on your local machine.
296 You should always use the best security mechanism available on your system to
297 protect your X server, be it XDM-AUTHORIZATION-1, XDM-MAGIC-COOKIE-1, or host
298 access control. *Never* just allow any machine to connect to your server
299 because, by doing so, you are allowing any machine to read any of your windows
300 or your keystrokes without you knowing it.
301
302 .SH SEE ALSO
303 .BR ftpd (8)
304 .BR login (1),
305 .BR opie (4),
306 .BR opiekeys (5),
307 .BR opieaccess (5),
308 .BR opiekey (1),
309 .BR opieinfo (1),
310 .BR opiepasswd (1),
311 .sp
312 Lamport, L. "Password Authentication with Insecure Communication",
313 Communications of the ACM 24.11 (November 1981), pp. 770-772.
314 .sp
315 Haller, N. "The S/KEY One-Time Password System", Proceedings of the ISOC
316 Symposium on Network and Distributed System Security, February 1994, 
317 San Diego, CA.
318 .sp
319 Haller, N. and Atkinson, R, "On Internet Authentication", RFC-1704,
320 DDN Network Information Center, October 1994.
321 .sp
322 Rivest, R. "The MD5 Message Digest Algorithm", RFC-1321,
323 DDN Network Information Center, April 1992.
324 .sp
325 Rivest, R. "The MD4 Message Digest Algorithm", RFC-1320,
326 DDN Network Information Center, April 1992.
327
328 .SH AUTHOR
329 Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S. Walden
330 of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan McDonald, and
331 Craig Metz.
332
333 S/Key is a trademark of Bell Communications Research (Bellcore).
334 UNIX is a trademark of X/Open.
335
336 .SH CONTACT
337 OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join,
338 send an email request to:
339 .sp
340 skey-users-request@thumper.bellcore.com