1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
/* options.h: Configuration options the end user might want to tweak.
%%% copyright-cmetz
This software is Copyright 1996 by Craig Metz, All Rights Reserved.
The Inner Net License Version 2 applies to this software.
You should have received a copy of the license with this software. If
you didn't get a copy, you may request one from <license@inner.net>.
History:
Created by cmetz for OPIE 2.3 using the old Makefile.source as a
guide.
*/
/*
Which hash should the OPIE server software use?
We strongly recommend that you use MD5. MD4 is faster, but less secure.
If you are migrating from Bellcore S/Key version 1 and wish to use the
existing key database, you must use MD4. In this case, you should consider
ways to re-key your users using MD5.
*/
#define MDX 5 /* Use MD5 */
/* #define MDX 4 /* Use MD4 */
/*
Ask users to re-type their secret pass phrases?
Doing so helps catch typing mistakes, but some users find it annoying.
*/
/* #define RETYPE 1 /* Ask users to re-type their secret pass phrases */
#define RETYPE 0 /* Don't ask users to re-type their secret pass phrases */
/*
Generater lock files to serialize OTP logins?
There is a potential race attack on OTP when more than one session can
respond to the same challenge at the same time. This locking only allows
one session at a time per principal (user) to attempt to log in using OTP.
The locking, however, creates a denial-of-service attack as a trade-off and
can be annoying if you have a legitimate need for two sessions to attempt
to authenticate as the same principal at the same time.
*/
#define USER_LOCKING 1 /* Serialize OTP challenges for a principal */
/* #define USER_LOCKING 0 /* Don't serialize OTP challenges */
/*
Should su(8) refuse to switch to disabled accounts?
Traditionally, su(8) can switch to any account, even if it is disabled.
In most systems, there is no legitimate need for this capability and it can
create security problems.
*/
#define SU_STAR_CHECK 1 /* Refuse to switch to disabled accounts */
/* #define SU_STAR_CHECK 0 /* Allow switching to disabled accounts */
/*
Should OPIE use more informative prompts?
The new-style, more informative prompts better indicate to the user what
is being asked for. However, some automated login scripts depend on the
wording of some prompts and will fail if you change them.
*/
#define NEW_PROMPTS 1 /* Use the more informative prompts */
/* #define NEW_PROMPTS 0 /* Use the more compatible prompts */
/*
Should the user be allowed to override "insecure" terminal checks?
The "insecure" terminal checks are designed to help make it more clear
to users that they shouldn't disclose their secret over insecure lines
by refusing to accept the secret directly. These checks aren't perfect and
sometimes will cause OPIE to refuse to work when it really should. Allowing
users to override the terminal checks also helps the process of creating
OTP sequences for users. However, allowing users to override the terminal
checks also allows users to shoot themselves in the foot, which isn't usually
what you want.
*/
#define INSECURE_OVERRIDE 0 /* Don't allow users to override the checks */
/* #define INSECURE_OVERRIDE 1 /* Allow users to override the checks */
|
