2
# Configuration for the OTP module.
5
# This module allows you to use various handheld OTP tokens
6
# for authentication (Auth-Type := otp). These tokens are
7
# available from various vendors.
9
# WARNING WARNING WARNING WARNING WARNING WARNING WARNING
11
# Many tokens use ANSI X9.9 to generate passcodes. Ask your
12
# vendor what algorithm they use. If they won't tell you, don't
15
# ANSI X9.9 has been withdrawn as a standard, due to the weakness
16
# of DES. An attacker can learn the token's secret by observing
17
# two challenge/response pairs. See ANSI document X9 TG-24-1999
18
# <URL:http://www.x9.org/docs/TG24_1999.pdf>.
20
# The obvious fix is to not display the challenge; the attacker
21
# will not have access to the plaintext. This is possible since
22
# most (all?) vendors of X9.9 tokens support a synchronous mode.
23
# So, in synchronous modes, the challenge presented to the user is
24
# NOT the challenge used for response calculation. See the
25
# accompanying docs for more information.
27
# You must list this module in BOTH the authorize and authenticate
28
# sections in order to use it. Challenges are generated by the
29
# authorization code, and responses verified by the authentication code.
30
# This is just "how freeradius works".
32
# File containing user:card_type:key entries.
33
# See otppasswd.sample for examples of legal entries.
34
# This file must be mode 0400 or 0600, and owned by the user
36
# (default: /etc/otppasswd)
37
#pwdfile = /etc/otppasswd
39
# State manager rendezvous point.
40
# (default: /var/run/lsmd/socket)
41
#lsmd_rp = /var/run/lsmd/socket
43
# Text to use for the challenge. The '%' character is
44
# disallowed, except that you MUST have a single "%s"
45
# sequence in the string; the challenge itself is
46
# inserted there. (default "Challenge: %s\n Response: ")
47
#challenge_prompt = "Challenge: %s\n Response: "
49
# Length of the challenge. Most tokens probably support a
50
# max of 8 digits. (range: 5-32 digits, default 6)
53
# Maximum time, in seconds, that a challenge is valid.
54
# (The user must respond to a challenge within this time.)
55
# It is also the minimal time between consecutive async mode
56
# authentications, a necessary restriction due to an inherent
57
# weakness of the RADIUS protocol which allows replay attacks.
61
# The number of times a user can give an incorrect response
62
# before they enter into "delay mode". 0 == infinite. In
63
# delay mode, authentication attempts will always fail during
64
# the delay period. The delay period starts at 1m and doubles
65
# for each successive failure up to a max of 32m (the clock
66
# starts at the time of the last authentication attempt).
70
# The number of times a user can give an incorrect response
71
# before they are locked out completely. 0 == no lockout.
72
# Any non-zero value is probably only useful if you aren't
73
# actively monitoring the server logs (tsk tsk), but want to
74
# know if an (active) user's account is being attacked. This
75
# value can be less than softfail, in which case users are
76
# never delayed, just simply locked out.
80
# Whether or not to allow synchronous mode authentication.
81
# If your X9.9 users can authenticate to multiple RADIUS
82
# servers, this should be "yes" for the primary/default
83
# server, and "no" for the others. It is critically
84
# important that only one server authenticate users
85
# synchronously as the state information is not shared
86
# across servers. It's not just the case that a user will
87
# be out of sync, the user (or an attacker!) will be able
88
# to reuse a password. This setting allows you to copy
89
# your /etc/otppasswd file to all servers without changing
90
# the card_type definition. (default: yes)
93
# Whether or not the user can enter the sync response before
94
# being challenged. This permits authentication where the
95
# NAS doesn't handle Access-Challenge requests. When using
96
# fast_sync, challenges are only issued on request
97
# (see challenge_req, below). allow_sync must be "yes" for
98
# this to work. If you are using pam_radius as a client,
99
# and you have fast_sync set to "no", you probably want to use
100
# the "skip_passwd" option in pam_radius. See also resync_req.
104
# Whether or not to allow asynchronous ("pure" challenge/
105
# response) mode authentication. You may wish to disable
106
# this and require that out-of-sync users resync from
107
# specifically secured terminals. This is the only
108
# safe way to allow async responses without implementing
109
# a site-specific challenge transform. See the accompanying
110
# docs for more info. (default: no)
113
# Special password that requests a challenge in fast_sync mode.
114
# allow_async must be "yes" for the response to be handled async.
115
# That is, if the user uses this as their password, they WILL
116
# get a challenge; but their response will only be tested against
117
# the expected async response if allow_async is "yes".
118
# (default: "challenge")
119
#challenge_req = "challenge"
121
# Like challenge_req, except that using this as the password
122
# additionally resyncs the token. You can set this to the same
123
# value as challenge_req if you want this behaviour all the time,
124
# eg if your tokens don't support async-without-resync. When
125
# not doing fast_sync, the token is always resynced.
126
# (default: "resync")
127
#resync_req = "resync"
129
# Whether the soft PIN (see accompanying docs) is prepended (yes)
130
# or appended (no) to the passcode.
134
# Tokens that are event synchronous can easily lose sync with
135
# the server, eg if the user plays with the token they will
136
# increment the token's event counter, leaving the server
137
# behind. This value is the max number of events the server
138
# will tolerate the user being ahead. Be careful setting
139
# this value, it is also the number of responses that will
140
# be accepted. This value has no effect for tokens that
141
# encode/include the event count in the response. See the
142
# accompanying docs for more info. (max: 10, default: 0)
145
# If rwindow_size and rwindow_delay are both non-zero, two
146
# consecutive correct sync passwords within the specified window,
147
# and within rwindow_delay seconds of each other, will override
148
# the "delay mode" forced by the softfail option and the user
149
# will be authenticated. It does not make sense for rwindow_size
150
# to be less than ewindow_size. Setting this value very high can
151
# encourage/aggravate DoS (CPU %util).
152
# (default rwindow_size: 0)
153
# (default rwindow_delay: 60)
157
# The following are MPPE settings. The otp module must be aware
158
# of these (at least for now), because we can't properly offload
159
# this to the mschap module. Note that MS-CHAP (v1) is strongly
160
# discouraged and does not build by default. All possible values
161
# are listed as {value = meaning}. Default values are first.
162
#mschapv2_mppe = {2 = required, 1 = optional, 0 = forbidden}
163
#mschapv2_mppe_bits = {2 = 128, 1 = 128 or 40, 0 = 40}
164
#mschap_mppe = {2 = required, 1 = optional, 0 = forbidden}
165
#mschap_mppe_bits = {2 = 128}
added
removed
raddb/otp.conf
