4. Considérations de sécurité (Security Considerations)
4.1 Authentification des clients utilisant l'authentification de base (Authentication of Clients using Basic Authentication)
Le schéma d'authentification de base (Basic Authentication Scheme) n'est pas une méthode sécurisée d'authentification des utilisateurs et ne protège en aucune façon l'entité transmise en texte clair sur le réseau physique. HTTP n'empêche pas l'utilisation de schémas d'authentification supplémentaires et de mécanismes de chiffrement pour augmenter la sécurité ou l'ajout d'améliorations (telles que des schémas utilisant des mots de passe à usage unique) à l'authentification de base.
Le défaut le plus grave de l'authentification de base est qu'elle entraîne essentiellement la transmission en texte clair du mot de passe de l'utilisateur sur le réseau physique. C'est ce problème que l'authentification par condensé (Digest Authentication) tente de résoudre.
Parce que l'authentification de base implique la transmission en texte clair des mots de passe, elle ne devrait pas être utilisée (sans améliorations) pour protéger des informations sensibles ou précieuses.
Une utilisation courante de l'authentification de base est à des fins d'identification -- exiger de l'utilisateur qu'il fournisse un nom d'utilisateur et un mot de passe comme moyen d'identification, par exemple, pour recueillir des statistiques d'utilisation précises sur un serveur. Lorsqu'elle est utilisée de cette manière, il est tentant de penser qu'il n'y a aucun danger à son utilisation si l'accès illicite aux documents protégés n'est pas une préoccupation majeure. Ceci n'est correct que si le serveur émet à la fois le nom d'utilisateur et le mot de passe aux utilisateurs et, en particulier, ne permet pas à l'utilisateur de choisir son propre mot de passe. Le danger est que les utilisateurs naïfs réutilisent fréquemment un seul mot de passe pour éviter la tâche de maintenir plusieurs mots de passe.
Si un serveur permet aux utilisateurs de sélectionner leurs propres mots de passe, alors la menace n'est pas seulement l'accès non autorisé aux documents sur le serveur, mais aussi l'accès non autorisé à toutes autres ressources sur d'autres systèmes que l'utilisateur protège avec le même mot de passe. De plus, dans la base de données de mots de passe du serveur, nombre de mots de passe peuvent également être les mots de passe des utilisateurs pour d'autres sites. Le propriétaire ou l'administrateur d'un tel système pourrait donc exposer tous les utilisateurs du système au risque d'accès non autorisé à tous ces autres sites si ces informations ne sont pas maintenues de manière sécurisée.
L'authentification de base est également vulnérable à l'usurpation par des serveurs contrefaits. Si un utilisateur peut être amené à croire qu'il se connecte à un hôte contenant des informations protégées par l'authentification de base alors qu'en fait il se connecte à un serveur ou une passerelle hostile, alors l'attaquant peut demander un mot de passe, le stocker pour une utilisation ultérieure et feindre une erreur. Ce type d'attaque n'est pas possible avec l'authentification par condensé. Les implémenteurs de serveurs devraient se protéger contre la possibilité de ce type de contrefaçon par des passerelles ou des scripts CGI.
4.2 Authentification des clients utilisant l'authentification par condensé (Authentication of Clients using Digest Authentication)
L'authentification par condensé (Digest Authentication) ne fournit pas un mécanisme d'authentification fort, comparée aux mécanismes basés sur des clés publiques.
Cependant, elle est significativement plus forte que (par exemple) CRAM-MD5, qui a été proposée pour une utilisation avec LDAP [10], POP et IMAP (voir RFC 2195 [9]). Elle est destinée à remplacer le mécanisme de base beaucoup plus faible et encore plus dangereux.
L'authentification par condensé n'offre aucune protection de confidentialité au-delà de la protection du mot de passe réel. Tout le reste de la requête et de la réponse est disponible pour un espion.
L'authentification par condensé n'offre qu'une protection d'intégrité limitée pour le message dans les deux directions. Si le mécanisme qop=auth-int est utilisé, alors les parties du message utilisées pour calculer les valeurs de la directive response des champs d'en-tête WWW-Authenticate et Authorization (voir section 3.2 ci-dessus) sont protégées. La plupart des champs d'en-tête et leurs valeurs peuvent être modifiés dans le cadre d'une attaque de l'homme du milieu.
L'authentification par condensé ne peut pas répondre aux besoins de nombreuses transactions HTTP sécurisées. Pour ces besoins, TLS ou SHTTP sont des protocoles plus appropriés. En particulier, l'authentification par condensé ne peut pas être utilisée pour une transaction nécessitant une protection de confidentialité. Néanmoins, l'authentification par condensé est à la fois utile et appropriée pour de nombreuses fonctions. Tout service utilisant actuellement l'authentification de base devrait passer à l'authentification par condensé dès que possible.
4.3 Valeurs de nonce à usage limité (Limited Use Nonce Values)
Le schéma par condensé utilise un nonce spécifié par le serveur pour amorcer la génération de la valeur request-digest (comme spécifié dans la section 3.2.2.1 ci-dessus). Comme le montre l'exemple de nonce dans la section 3.2.1, le serveur est libre de construire le nonce de manière à ce qu'il ne puisse être utilisé que depuis un client particulier, pour une ressource particulière, pendant une période de temps ou un nombre d'utilisations limité, ou toute autre restriction. Cela renforce la protection fournie contre, par exemple, les attaques par rejeu (voir 4.5). Cependant, il convient de noter que la méthode choisie pour générer et vérifier le nonce a également des implications en termes de performances et de ressources.
4.4 Comparaison du condensé avec l'authentification de base (Comparison of Digest with Basic Authentication)
L'authentification par condensé et l'authentification de base sont toutes deux faibles dans le sens où elles peuvent ne pas empêcher l'accès non autorisé par un adversaire déterminé. Cependant, la comparaison entre les deux met en évidence l'utilité, et peut-être même la nécessité, de remplacer l'authentification de base par l'authentification par condensé.
Pour le type de transactions pour lesquelles ce protocole est susceptible d'être utilisé, la plus grande menace est l'écoute réseau. Ce type de transaction pourrait impliquer, par exemple, l'accès en ligne à une base de données dont l'utilisation est réservée aux abonnés payants. Avec l'authentification de base, un espion peut obtenir le mot de passe de l'utilisateur. Cela lui permet non seulement d'accéder à tout ce qui se trouve dans la base de données, mais, ce qui est souvent pire, permettra l'accès à tout ce que l'utilisateur protège avec le même mot de passe.
En revanche, avec l'authentification par condensé, l'espion n'obtient l'accès qu'à la transaction en question, et non au mot de passe de l'utilisateur. Les informations obtenues par l'espion permettraient une attaque par rejeu, mais uniquement avec la même requête de document, et même cela peut être limité par le choix du nonce par le serveur.
4.5 Attaques par rejeu (Replay Attacks)
Les attaques par rejeu avec l'authentification par condensé sont généralement sans signification pour les simples requêtes GET, car l'espion a déjà vu le seul document qu'il pourrait obtenir en rejouant. C'est parce que l'URI du document demandé est condensé dans la requête du client, et le serveur ne livrera que ce document. En revanche, avec l'authentification de base, une fois que l'espion a le mot de passe de l'utilisateur, tout document protégé par ce mot de passe lui est ouvert.
Par conséquent, à certaines fins, il est nécessaire de se protéger contre les attaques par rejeu. Les bonnes implémentations de condensé peuvent le faire de diverses manières. La valeur "nonce" créée par le serveur dépend de l'implémentation, mais si elle contient un condensé de l'IP du client, d'un horodatage, de l'ETag de la ressource et d'une clé privée du serveur (comme recommandé ci-dessus), alors une attaque par rejeu n'est pas simple.
Pour les applications qui ne peuvent tolérer même la possibilité d'attaques par rejeu, le serveur peut utiliser des valeurs de nonce à usage unique qui ne sont pas acceptées une seconde fois. Cela nécessite le surcoût pour le serveur de se souvenir quelles valeurs de nonce ont été utilisées jusqu'à expiration de l'horodatage du nonce.
4.6 Faiblesse créée par plusieurs schémas d'authentification (Weakness Created by Multiple Authentication Schemes)
Lorsqu'un serveur propose plusieurs schémas d'authentification dans l'en-tête WWW-Authenticate, le client devrait sélectionner le schéma le plus fort qu'il supporte. Cependant, si un attaquant peut modifier la réponse pour supprimer le schéma le plus fort, le client peut être forcé d'utiliser un schéma plus faible.
4.7 Attaques par dictionnaire en ligne (Online dictionary attacks)
Si le serveur ne limite pas le taux de tentatives d'authentification, un attaquant peut essayer un grand nombre de mots de passe pour deviner le correct. Les serveurs devraient limiter le taux de tentatives d'authentification échouées provenant d'une seule adresse IP.
4.8 Homme du milieu (Man in the Middle)
L'authentification par condensé est vulnérable aux attaques de l'homme du milieu. Un attaquant peut intercepter les communications entre le client et le serveur et modifier ou remplacer les messages. L'utilisation de TLS ou d'autres mécanismes de sécurité de la couche transport peut empêcher de telles attaques.
4.9 Attaques par texte clair choisi (Chosen plaintext attacks)
L'authentification par condensé est vulnérable aux attaques par texte clair choisi. Un attaquant peut choisir des URI spécifiques et observer les condensés résultants, obtenant potentiellement des informations sur le mot de passe.
4.10 Attaques par dictionnaire précalculé (Precomputed dictionary attacks)
Si un attaquant peut accéder au fichier de mots de passe du serveur, il peut précalculer des condensés de mots de passe courants, puis comparer ces condensés avec ceux du fichier. L'utilisation de valeurs de sel (Salt) peut rendre cette attaque plus difficile.
4.11 Attaques par force brute par lot (Batch brute force attacks)
Si un attaquant peut capturer plusieurs échanges d'authentification, il peut tenter de forcer brutalement le mot de passe hors ligne. L'utilisation de mots de passe forts et la limitation de la période de validité des nonces peuvent atténuer ce risque.
4.12 Usurpation par des serveurs contrefaits (Spoofing by Counterfeit Servers)
Les clients devraient vérifier l'identité du serveur pour éviter de se connecter à des serveurs contrefaits. L'utilisation de TLS avec validation du certificat du serveur peut empêcher de telles attaques.
4.13 Stockage des mots de passe (Storing passwords)
Les serveurs ne devraient pas stocker les mots de passe en texte clair. Au lieu de cela, le hachage du mot de passe devrait être stocké. Pour l'authentification par condensé, le serveur peut stocker H(username:realm:password), ce qui permet la vérification du client sans stocker les mots de passe en texte clair.
4.14 Résumé (Summary)
L'authentification par condensé fournit une meilleure sécurité que l'authentification de base, mais ce n'est pas une solution de sécurité complète. Pour les applications nécessitant une sécurité forte, TLS ou d'autres mécanismes de sécurité plus forts devraient être utilisés. Néanmoins, l'authentification par condensé est une amélioration pratique et utile pour de nombreuses applications.