Quels sont les inconvénients de l'implémentation de l'authentification HTTP dans une application Web?
Je sais qu'il existe différents types de mécanismes d'authentification disponibles. L'un d'eux est l'authentification HTTP. Quel est le danger à utiliser cette méthode par rapport à d'autres méthodes?
L'authentification de base présente un certain nombre d'inconvénients, dont l'un est que le nom d'utilisateur et le mot de passe sont transmis en clair à chaque demande. Ceci est clairement dangereux sous HTTP, mais est un peu moins vulnérable sous HTTPS. Cependant, comme les informations d'identification sont soumises avec chaque demande, c'est encore pire que toute autre méthode (y compris le résumé) qui n'a pas cette limitation. La raison principale est que désormais chaque demande peut être une cible pour le vol d'informations d'identification en texte clair, et pas seulement une demande de connexion initiale. Dans la plupart des systèmes, après la connexion, le maximum qu'un attaquant puisse espérer récupérer est une session ou un jeton d'authentification. Avec l'authentification de base, toute demande est l'occasion de voler le mot de passe de l'utilisateur. Ce n'est pas l'idéal.
L'authentification du résumé est un peu meilleure en ce sens qu'elle envoie un résumé MD5 de divers bits, y compris le nom d'utilisateur, le mot de passe et un nonce (entre autres valeurs) et non les informations d'identification en texte clair ... Un mot de passe ne peut pas être extrait d'un résumé capturé.
Avec l'authentification HTTP (sous n'importe quelle forme), vous dépendez également du client pour fournir l'expérience utilisateur d'authentification, qui peut avoir ses propres problèmes et doit donc être bien testée avec les clients que vous prévoyez d'utiliser votre application. Dans le passé, par exemple, j'ai vu des navigateurs spécifiques ne pas s'authentifier à cause de certains caractères spéciaux dans un mot de passe, par exemple. Avec l'authentification basée sur l'application UX, vous avez le contrôle sur cela. Avec l'authentification HTTP, ce n'est pas le cas.
Une autre attaque (et c'est très mineur) est que si vous affichez du contenu généré par l'utilisateur et hébergé en externe sur votre site, vous vous ouvrez à des attaques de phishing 401 très subtiles. Étant donné que vos utilisateurs sont habitués au client chrome pour l'authentification HTTP, ils ne remarqueront pas nécessairement s'ils obtiennent une invite d'authentification sur votre site pour un domaine légèrement différent. Selon votre application, cela peut n'est pas du tout une menace valide, mais c'est certainement quelque chose à considérer si vous suivez la route d'authentification HTTP.
En plus des autres points mentionnés, un autre inconvénient important de l'authentification de base HTTP (vs, disons, la connexion basée sur les formulaires) est qu'il n'a pas de concept de "déconnexion". Une fois que l'utilisateur a entré ses informations d'identification, le navigateur les stocke en interne pour les envoyer à chaque demande ultérieure. Cela signifie que vous ne pouvez pas avoir de délai d'expiration ou de bouton/lien de déconnexion pour terminer la session. Si l'utilisateur souhaite éviter que quelqu'un d'autre utilise sa session (par exemple dans le cas d'un ordinateur partagé), il doit se rappeler de quitter le navigateur.
Pour plus de lecture: https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
L'authentification d'accès de base sur HTTPS présente des avantages évidents par rapport à l'authentification d'accès Digest sur HTTP.
Même avec l'authentification d'accès Digest, vous pouvez réellement stocker vos mots de passe hachés avec un sel unique (domaine + nom d'utilisateur), mais d'abord ce sel est devinable (cela facilite les attaques contre les utilisateurs uniques et les petits groupes), et ensuite vous ne pouvez pas utiliser bcrypt, scrypt ou PBKDF2 pour rendre le calcul de hachage plus difficile. De plus, si vous avez choisi de stocker les hachages dans un format non récupérable (ce que vous devriez faire!), Vous ne pouvez pas changer le domaine sans exiger le mot de passe utilisateur clair.
Dans SASL , digérer l'authentification d'accès même a été marqué comme historique par IETF. Pour SASL, ils avaient une alternative ( SCRAM , exigeant clairement SASLPrep pour la normalisation des caractères par exemple) qu'ils pourraient recommander d'utiliser à la place. SCRAM pour HTTP a malheureusement n'a jamais passé le statut de brouillon (Notez qu'avec SCRAM, les sels de l'utilisateur ne sont pas secrets non plus. L'attaquant peut abuser du mécanisme de connexion pour obtenir des sels pour chaque utilisateur de leur choix).
L'authentification d'accès au résumé peut donner un faux sentiment de sécurité . Si l'attaquant peut capturer une connexion réussie, il peut monter une attaque par force brute contre le mot de passe. username, realm et nonce sont toutes des valeurs connues pour l'attaquant.
L'utilisation de HTTP non chiffré, avec ou sans authentification d'accès Digest, n'est pas à l'abri de MITM. L'attaquant peut ne pas être en mesure d'attraper le mot de passe, mais il peut capturer les cookies de session et modifier le contenu ou usurper l'identité de l'utilisateur.
Avec l'authentification d'accès de résumé est uniquement spécifié pour la connexion, mais pas pour la configuration du compte. Vous devez configurer le compte de la "manière habituelle". Même si votre code est intelligent et qu'il n'envoie que le hachage interne pour empêcher le mot de passe d'être transporté en texte clair, il peut être modifié par l'attaquant pour le lui transmettre également. Cependant, ce grave problème n'existe qu'une seule fois, lors de l'inscription . En supposant que l'utilisateur se connecte à partir d'une petite quantité de machines, vous pouvez obtenir une sécurité similaire en utilisant TACK pour HTTPS. Cela permet au navigateur de l'utilisateur d'autoriser uniquement le certificat obtenu lors de la première connexion au site. Ainsi, seule la première connexion reste exposée à un éventuel MITM, tout comme avec l'authentification d'accès Digest.