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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
|
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision : 1673947 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_auth_digest.xml.meta">
<name>mod_auth_digest</name>
<description>Authentification utilisateur utilisant les condensés
MD5</description>
<status>Extension</status>
<sourcefile>mod_auth_digest.c</sourcefile>
<identifier>auth_digest_module</identifier>
<summary>
<p>Ce module implémente l'authentification HTTP basée sur les
condensés MD5 (<a
href="http://www.faqs.org/rfcs/rfc2617.html">RFC2617</a>), et
fournit une alternative à <module>mod_auth_basic</module> en
ne transmettant plus le mot de passe en clair. Cependant, cela ne
suffit pas pour améliorer la sécurité de manière significative par
rapport à l'authentification basique. En outre, le stockage du mot
de passe sur le serveur est encore moins sûr dans le cas
d'une authentification à base de condensé que dans le cas d'une
authentification basique. C'est pourquoi l'utilisation de
l'authentification basique associée à un chiffrement de la connexion
via <module>mod_ssl</module> constitue une bien meilleure
alternative.</p>
</summary>
<seealso><directive module="mod_authn_core">AuthName</directive></seealso>
<seealso><directive module="mod_authn_core">AuthType</directive></seealso>
<seealso><directive module="mod_authz_core">Require</directive></seealso>
<seealso><a href="../howto/auth.html">Mode d'emploi de
l'authentification</a></seealso>
<section id="using"><title>Utilisation de l'authentification à base de
condensés</title>
<p>Pour utiliser l'authentification à base de condensés MD5, vous
devez simplement remplacer <code>AuthType Basic</code> et <directive
module="mod_auth_basic">AuthBasicProvider</directive> respectivement
par <code>AuthType Digest</code> et <directive
module="mod_auth_digest">AuthDigestProvider</directive> lorsque vous
configurez l'authentification, puis ajouter une directive <directive
module="mod_auth_digest">AuthDigestDomain</directive> contenant au
moins la(les) URI(s) racine(s) de la zone à protéger.</p>
<p>On peut créer les fichiers utilisateur appropriés (au format
texte) à l'aide de l'outil <program>htdigest</program>.</p>
<example><title>Exemple :</title>
<highlight language="config">
<Location "/private/">
AuthType Digest
AuthName "private area"
AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
AuthDigestProvider file
AuthUserFile "/web/auth/.digest_pw"
Require valid-user
</Location>
</highlight>
</example>
<note><title>Note</title>
<p>L'authentification à base de condensé a été conçue pour améliorer
la sécurité par rapport à l'authentification basique, mais il
s'avère que ce but n'a pas été atteint. Un attaquant de type
"man-in-the-middle" peut facilement forcer le navigateur à revenir à
une authentification basique. Même une oreille indiscrète passive
peut retrouver le mot de passe par force brute avec les moyens
modernes, car l'algorithme de hashage utilisé par l'authentification
à base de condensé est trop rapide. Autre problème, le stockage des
mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier
htdigest volé peut être utilisé directement pour l'authentification
à base de condensé. Il est donc fortement recommandé d'utiliser
<module>mod_ssl</module> pour chiffrer la connexion.</p>
<p><module>mod_auth_digest</module> ne fonctionne correctement que
sur les plates-formes où APR supporte la mémoire partagée.</p>
</note>
</section>
<directivesynopsis>
<name>AuthDigestProvider</name>
<description>Définit le(s) fournisseurs(s) d'authentification pour la
zone du site web concernée</description>
<syntax>AuthDigestProvider <var>nom fournisseur</var>
[<var>nom fournisseur</var>] ...</syntax>
<default>AuthDigestProvider file</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>La directive <directive>AuthDigestProvider</directive> permet de
définir quel fournisseur d'authentification sera utilisé pour
authentifier les utilisateurs pour la zone du site web concernée.
Assurez-vous que le module implémentant le fournisseur
d'authentification choisi soit bien présent dans le serveur. Le
fournisseur par défaut <code>file</code> est implémenté par le
module <module>mod_authn_file</module>.</p>
<p>Voir <module>mod_authn_dbm</module>,
<module>mod_authn_file</module>, <module>mod_authn_dbd</module> et
<module>mod_authn_socache</module>
pour la liste des fournisseurs disponibles.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestQop</name>
<description>Détermine le niveau de protection fourni par
l'authentification à base de condensé</description>
<syntax>AuthDigestQop none|auth|auth-int [auth|auth-int]</syntax>
<default>AuthDigestQop auth</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>La directive <directive>AuthDigestQop</directive> permet de
définir le <dfn>niveau de protection</dfn> fourni. <code>auth</code>
ne fournit que l'authentification (nom utilisateur/mot de passe) ;
<code>auth-int</code> fournit l'authentification plus un contrôle
d'intégrité (un condensé MD5 de l'entité est aussi calculé et
vérifié) ; avec <code>none</code>, le module va utiliser l'ancien
algorithme de condensés RFC-2069 (qui n'effectue pas de contrôle
d'intégrité). On peut spécifier à la fois <code>auth</code> et
<code>auth-int</code>, auquel cas c'est le navigateur qui va choisir
lequel des deux utiliser. <code>none</code> ne doit être utilisé que
dans le cas où le navigateur ne serait pas à même (pour une raison
ou pour une autre) de relever le défit qu'il recevrait si un autre
niveau de protection était défini.</p>
<note>
<code>auth-int</code> n'est pas encore implémenté.
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestNonceLifetime</name>
<description>Durée de validité du nombre à valeur unique du
serveur (nonce)</description>
<syntax>AuthDigestNonceLifetime <var>secondes</var></syntax>
<default>AuthDigestNonceLifetime 300</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>La directive <directive>AuthDigestNonceLifetime</directive>
permet de contrôler la durée de validité du nombre à valeur unique
du serveur (nonce). Lorsque le client contacte le serveur en
utilisant un nonce dont la validité a expiré, le serveur renvoie un
code d'erreur 401 avec <code>stale=true</code>. Si
<var>secondes</var> est supérieur à 0, il spécifie la durée de
validité du nonce ; il est en général déconseillé d'affecter à cet
argument une valeur inférieure à 10 secondes. Si
<var>secondes</var> est inférieur à 0, le nonce n'expire jamais.
<!-- Pas encore implémenté : si <var>secondes</var> est égal à 0, le
client ne doit utiliser le nonce qu'une seule fois. Notez que si les
nonces à usage unique assurent une sécurité accrue contre les
attaques à base de rejeu, il ont aussi d'importantes implications en
matière de performances, car le navigateur ne peut plus alors
effectuer de requêtes en paralléle (pipelining) ou utiliser
plusieurs connexions pour une même requête. Comme il n'est pas aisé
pour les navigateurs de détecter l'utilisation de nonces à usage
unique, on peut aboutir à la situation où le navigateur va tenter
d'effectuer des requêtes en parallèle et recevoir des codes d'erreur
401 pour toutes les requêtes sauf la première, ce qui aura pour
effet de lui faire renvoyer les requêtes. Notez aussi que la
protection contre les attaques à base de rejeu n'a de sens que dans
le cas de contenus générés dynamiquement ou de requêtes de type
POST ; dans le cas des contenus statiques, l'attaquant possède déjà
probablement la réponse complète, et les nonces à usage unique sont
ici sans objet. -->
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestNonceFormat</name>
<description>Détermine la manière dont le nombre à valeur unique du
serveur (nonce) est généré</description>
<syntax>AuthDigestNonceFormat <var>format</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<note>Non encore implémenté.</note>
<!-- La directive AuthDigestNonceFormat permet de déterminer la
manière dont le nombre à valeur unique du serveur (nonce) est
généré. -->
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestNcCheck</name>
<description>Active ou désactive la vérification du nombre d'envois du
nombre à valeur unique (nonce) par le serveur</description>
<syntax>AuthDigestNcCheck On|Off</syntax>
<default>AuthDigestNcCheck Off</default>
<contextlist><context>server config</context></contextlist>
<usage>
<note>
Non encore implémenté.
</note>
<!--
<p>La directive AuthDigestNcCheck permet d'activer ou de désactiver
la vérification du nombre d'envois du nombre à valeur unique (nonce)
par le serveur.</p>
<p>Bien que la définition de cette directive à On soit recommandée
du point de vue de la sécurité, elle a des conséquences importantes sur
les performances du serveur. Pour vérifier le nombre d'envois du nonce,
*toutes* les requêtes (du moins toutes celles qui possèdent un
en-tête d'autorisation, qu'elles requièrent ou non une
authentification à base de condensé) doivent être sérialisées au
travers d'une section critique. Si le serveur traite un grand nombre
de requêtes qui possèdent un en-tête d'autorisation, l'impact sur
les performances pourra se montrer sensible.</p>
-->
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestAlgorithm</name>
<description>Sélectionne l'algorithme utilisé pour calculer les
condensés du défit et de sa réponse</description>
<syntax>AuthDigestAlgorithm MD5|MD5-sess</syntax>
<default>AuthDigestAlgorithm MD5</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>La directive <directive>AuthDigestAlgorithm</directive> permet de
sélectionner l'algorithme utilisé pour calculer les condensés du
défit et de sa réponse.</p>
<note>
<code>MD5-sess</code> n'est pas encore correctement implémenté.
</note>
<!--
<p>Pour pouvoir utiliser <code>MD5-sess</code>, vous devez tout
d'abord éditer le code de la fonction <code>get_userpw_hash()</code>
dans <code>mod_auth_digest.c</code>.</p>
-->
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestDomain</name>
<description>Les URIs qui se trouvent dans le même espace de protection
concernant l'authentification à base de condensés</description>
<syntax>AuthDigestDomain <var>URI</var> [<var>URI</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>La directive <directive>AuthDigestDomain</directive> vous permet
de spécifier un ou plusieurs URIs se trouvant dans le même
espace de protection (c'est à dire utilisant le même utilisateur/mot
de passe et se trouvant dans le même domaine). Les URIs spécifiés
sont des préfixes ; le client doit savoir que tous les URIs situés
sous ces préfixes seront protégés par le même utilisateur/mot de
passe. Les URIs peuvent être soit des URIs absolus (c'est à dire
avec protocole, nom serveur, port, etc...), soit des URIs
relatifs.</p>
<p>Cette directive doit toujours être présente et contenir au moins
le(s) URI(s) racine(s) pour cet espace. Dans le cas contraire, le
client va envoyer un en-tête d'autorisation avec <em>chaque
requête</em> à destination de ce serveur. Outre une augmentation de
la taille de la requête, les performances vont s'en trouver
affectées si la directive <directive
module="mod_auth_digest">AuthDigestNcCheck</directive> est définie à
On.</p>
<p>Les URIs spécifiés peuvent aussi référencer différents serveurs,
auquel cas les clients (qui sont à même de le comprendre) vont
partager l'utilisateur/mot de passe entre plusieurs serveurs sans le
demander à l'utilisateur à chaque fois.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDigestShmemSize</name>
<description>La quantité de mémoire partagée à allouer afin de conserver
les informations à propos des clients</description>
<syntax>AuthDigestShmemSize <var>taille</var></syntax>
<default>AuthDigestShmemSize 1000</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p>La directive <directive>AuthDigestShmemSize</directive> permet de
définir la quantité de mémoire partagée à allouer au démarrage du
serveur afin de conserver les informations à propos des clients.
Notez que le segment de mémoire partagée ne peut pas être défini à
une taille inférieure à l'espace nécessaire pour conserver les
informations à propos d'<em>un</em> client. Cette valeur dépend de
votre système. Si vous voulez en déterminer la valeur exacte, vous
pouvez simplement définir <directive>AuthDigestShmemSize</directive>
à <code>0</code> et consulter le message d'erreur que renverra le
serveur lorsqu'on essaiera de le démarrer.</p>
<p>L'argument <var>size</var> s'exprime par défaut en octets, mais
vous pouvez suffixer le nombre par un <code>K</code> ou un
<code>M</code> pour spécifier respectivement des KiloOctets ou des
MégaOctets. Par exemple, les directives qui suivent sont toutes
équivalentes :</p>
<highlight language="config">
AuthDigestShmemSize 1048576
AuthDigestShmemSize 1024K
AuthDigestShmemSize 1M
</highlight>
</usage>
</directivesynopsis>
</modulesynopsis>
|
