Sécuriser les authentifications Htaccess avec l’option Digest
I. Présentation
Le fichier .htaccess est un moyen rapide et efficace pour restreindre et protéger l'accès à un dossier ou à des fichiers web sur un serveur. La plupart des tutoriels nous disent souvent d'utiliser l'option simple "AuthType Basic" pour la méthode d'authentification. Cependant, cette option fait passer les mots de passe quasiment en clair sur le réseau remettant ainsi sérieusement en cause leur crédibilité en terme de sécurité. Dans ce tutoriel, nous allons voir une démonstration du passage du mot de passe lors d'une authentification .htaccess utilisant un type d'authentification "Basic" puis nous verrons comment mieux sécuriser le passage de l'authentification sur le réseau par un .htaccess.
II. Démonstration
Nous partons ici du fait qu'un fichier ".htaccess" utilisant l'"AuthType Basic" est déjà en place. Pour ceux pour qui ce ne serait pas encore le cas, je vous oriente vers ce tutoriel sur la mise en place d'une protection simple avec ".htaccess". Nous allons donc avoir un serveur web (dans mon exemple ayant l'IP 192.168.1.13) avec un accès restreints sur "/var/www" ( URL d'accès http://192.168.1.13) par une page ".htaccess" ayant le contenu simplifié suivant :
AuthType Basic AuthName "Accès restreints" AuthUserFile /var/www/.htpasswd Require user valid-user
Pour rappel, le fichier contenant les identifiants est créé avec la commande "htpasswd -c .htpasswd user". Lors d'une connexion et d'une authentification, nous écoutons le trafic avec un analyseur de paquets comme Wireshark, voici le résultat que nous avons :
On voit donc bien l'échange fait entre les machines, d'abord l'initialisation de la communication sur les trois premiers paquets, la demande d'authentification ("Authorization Required") sur le paquet n°22 et enfin le paquet où les identifiants sont échangés au paquet n°34. Regardons d'un peu plus prés le contenu de ce paquet :
Nous voyons bien ici dans la partie "HTTP" du paquet les credentials ("identifiants") envoyés par le client (192.168.1.14) au serveur (192.168.1.13). Le mode d'authentification "Basic" encode les identifiants (bmVh ...) mais d'une façon si simple que WireShark les décodes automatiquement pour nous afficher les vrais identifiants (login : neaj, mot de passe : neajpasswd). L'encodage en base 64 est un procédé servant à coder du binaire en ASCII et inversement. Nous pouvons très simplement avec un décodeur récupérer manuellement la chaine encodée et la décodée comme suivant :
Source: http://www.base64decode.org/
Nous voyons donc ici clairement que les mots de passe sont récupérables par un sniff du réseau lors d'une authentification ".htaccess". Pour information, l'"AuthType Basic" utilise le module "auth_basic_module" d'Apache2 qui est activé par défaut. A nous de sécuriser un peu plus ces échanges.
III. L'option Digest
Comme dit précédemment, l'option la plus utilisée est l'"AuthType Basic", nous pouvons cependant en utiliser une autre qui est la "Digest", celle-ci utilise le module "mod_auth_digest" et se charge de hasher les identifiants en MD5 ce qui est un peu plus sécurisé ( pas totalement l'utilisation de mots de passe triviaux couplés aux "rainbow tables" peut être dangereux) . Nous devons donc commencer par activer ce module sur notre serveur Apache 2 car il ne l'est pas par défaut :
a2enmode auth_digest service apache2 reload
Nous allons ensuite modifier quelque peut notre fichier ".htaccess" pour qu'il permette l'utilisation de la méthode d'authentification "Digest" :
AuthType Digest AuthName "Private" AuthUserFile /var/www/.htpasswd Require user valid-user
Note : Nous avons ici simplifié l'AuthName car il devient une caractéristique à mettre dans le fichier contenant les identifiants.
On va ensuite encoder notre fichier ".htpasswd" qui contient les identifiants en "Digest" avec la commande "htdigest" (au lieu de "htpasswd").
htdigest .htpasswd "Private" neaj
Note : "Private" est ici la valeur que nous avons mis dans l'option "AuthName" du fichier ".htaccess"
On saisi ensuite deux fois notre mot de passe puis nous procédons à l'authentification sur notre serveur en faisant encore une fois une analyse des paquets que s'échangent les machines avec Wireshark :
En apparence rien n'a changé lors de l'échange entre les serveurs.
Note: Sous Wireshark, mettez "http" dans le filtre pour ne voir que les échanges HTTP.
Cependant si nous regardons le contenu du paquet HTTP qui transmet les identifiants du client au serveur, nous voyons une différence :
Nous voyons en effet que nos identifiants (du moins le mot de passe de l'utilisateur) ne passent plus en clair sur le réseau lors de l'authentification de notre client sur le serveur.
Merci pour cette page d’aide, je cherche depuis ce matin à comprendre comment fonctionne la protection des mots de passe avec Digest, et dans aucune des nombreuses pages, même les plus détaillées, qui en parlent, on n’explique le rôle du AuthName spécifié dans .htaccess pour la création et le décodage des mots de passe encryptés…
La dernière ligne de marche pas chez moi.
Require user valid-user
J’ai mis :
Require valid-user
Un grand merci d’avoir partagé un contenu aussi incroyable. C’est toujours un plaisir d’avoir un tel contenu plein de connaissances. Le bon article organisé. Les mots sont soutenus par des images. Cela m’aide vraiment à comprendre comment fonctionne la protection par mot de passe. J’attends plus de votre part. À votre santé.
Le fait d’être en SSL dispense t’il de se mettre en digest ?
Cdt
Je trouve le md5 complètement useless.. Je trouve que le mieux reste l’utilisation d’une base de donnée avec des utilisateurs et des mot de passes hashés donnant droit ou nom à accéder à X informations (si pas de droit redirection vers l’accueil).