4. Considérations de sécurité
Le schéma d'authentification Basic n'est pas une méthode sécurisée d'authentification des utilisateurs, et ne protège en aucune façon l'entité, qui est transmise en texte clair sur le réseau physique utilisé comme support. HTTP n'empêche pas l'ajout d'améliorations (telles que des schémas utilisant des mots de passe à usage unique) à l'authentification Basic.
Le défaut le plus grave de l'authentification Basic est qu'elle entraîne la transmission en texte clair du mot de passe de l'utilisateur sur le réseau physique. De nombreux autres schémas d'authentification résolvent ce problème.
Étant donné que l'authentification Basic implique la transmission en texte clair des mots de passe, elle NE DEVRAIT PAS être utilisée (sans améliorations telles que HTTPS [RFC2818]) pour protéger des informations sensibles ou précieuses.
Une utilisation courante de l'authentification Basic est à des fins d'identification -- exiger que l'utilisateur fournisse un user-id et un mot de passe comme moyen d'identification, par exemple, à des fins de collecte de 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 dans 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 délivre à la fois le user-id et le mot de passe aux utilisateurs et, en particulier, ne permet pas à l'utilisateur de choisir son propre mot de passe. Le danger survient parce 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 les 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, beaucoup 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. Cela soulève des préoccupations tant en matière de sécurité que de confidentialité ([RFC6973]). Si la même combinaison user-id/mot de passe est utilisée pour accéder à d'autres comptes, tels qu'un compte de messagerie ou un portail de santé, des informations personnelles pourraient être exposées.
L'authentification Basic est également vulnérable à l'usurpation d'identité 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 Basic alors qu'en fait, il se connecte à un serveur ou une passerelle hostile, l'attaquant peut demander un mot de passe, le stocker pour une utilisation ultérieure et simuler une erreur. Les implémenteurs de serveurs devraient se protéger contre ce type de contrefaçon; en particulier, les composants logiciels qui peuvent prendre le contrôle du cadrage des messages sur une connexion existante doivent être utilisés avec précaution ou pas du tout (par exemple: les scripts NPH ("Non-Parsed Header") tels que décrits dans la section 5 de [RFC3875]).
Les serveurs et proxys implémentant l'authentification Basic doivent stocker les mots de passe des utilisateurs sous une certaine forme afin d'authentifier une demande. Ces mots de passe devraient être stockés de manière à ce qu'une fuite des données de mot de passe ne les rende pas trivialement récupérables. Ceci est particulièrement important lorsque les utilisateurs sont autorisés à définir leurs propres mots de passe, car les utilisateurs sont connus pour choisir des mots de passe faibles et les réutiliser à travers les realms d'authentification. Bien qu'une discussion complète des bonnes techniques de hachage de mots de passe dépasse la portée de ce document, les opérateurs de serveurs devraient faire un effort pour minimiser les risques pour leurs utilisateurs en cas de fuite de données de mots de passe. Par exemple, les serveurs devraient éviter de stocker les mots de passe des utilisateurs en texte clair ou sous forme de condensés non salés. Pour plus de discussion sur les techniques modernes de hachage de mots de passe, voir le "Password Hashing Competition" (https://password-hashing.net).
L'utilisation du schéma d'encodage de caractères UTF-8 et de la normalisation introduit des considérations de sécurité supplémentaires; voir la section 10 de [RFC3629] et la section 6 de [RFC5198] pour plus d'informations.