68
En quoi l'authentification Digest diffère-t-elle de l'authentification de base autre que l'envoi d'informations d'identification en texte brut?Qu'est-ce que l'authentification Digest?
A
Répondre
112
La principale différence est qu'il ne nécessite pas d'envoyer le nom d'utilisateur et mot de passe à travers le fil en texte clair. Il est également immunisé contre les rejeu-attaques, car il utilise un numéro unique du serveur.
Le serveur donne au client un numéro d'utilisation unique (un nonce) qu'il combine avec le nom d'utilisateur, le domaine, le mot de passe et la demande d'URI. Le client exécute tous ces champs via une méthode de hachage MD5 pour produire une clé de hachage.
Il envoie cette clé de hachage au serveur avec le nom d'utilisateur et le domaine pour tenter de s'authentifier. Côté serveur La même méthode est utilisée pour générer un hashkey, mais au lieu d'utiliser le mot de passe tapé dans le navigateur, le serveur recherche le mot de passe attendu pour l'utilisateur à partir de sa base de données utilisateur. Il recherche le mot de passe stocké pour ce nom d'utilisateur, s'exécute par le même algorithme et le compare à ce que le client a envoyé. Si elles correspondent, l'accès est accordé, sinon il peut renvoyer un 401 non autorisé (pas de connexion ou un échec de connexion) ou un 403 Interdit (accès refusé).
L'authentification Digest est standardized in RFC2617. Il y a un nice overview of it on Wikipedia:
Vous pouvez penser comme ceci:
- client fait la demande
- client récupère un nonce à partir du serveur et une demande d'authentification 401
- client renvoie la réponse suivante array (nom d'utilisateur, domaine, generate_md5_key (nonce, nom d'utilisateur, domaine, URI, password_given_by_user_to_browser)) (oui, ce qui est très simplifiée)
- le serveur prend le nom d'utilisateur et domaine (plus il connaît l'URI le client demande) et Loo ks le mot de passe pour ce nom d'utilisateur. Puis il va et fait sa propre version de generate_md5_key (nonce, nom d'utilisateur, domaine, URI, password_I_have_for_this_user_in_my_db)
- Il compare la sortie de generate_md5() qu'il a obtenu avec celui que le client a envoyé, si elles correspondent au client envoyé le bon mot de passe. Si elles ne correspondent pas, le mot de passe envoyé était erroné.
+0
Belle explication. Est-ce que le nom d'utilisateur et pwd pour un utilisateur Windows? D'où proviennent-ils? – SoftwareGeek
+0
Ils sont tout ce que l'utilisateur tape dans le navigateur. Le mot de passe doit correspondre à tout ce que le serveur a stocké pour le mot de passe de cet utilisateur. Plus probablement qu'autrement, c'est quelque chose de spécifique à cette application web et non votre mot de passe Windows. Cela dépend beaucoup de la manière dont l'application Web est assemblée. –
+7
Cette réponse a 6 ans, mais je suppose que tous les systèmes de sécurité stockent les mots de passe dans un format de hachage salé maintenant. Il n'y a pas, et il ne devrait y avoir aucune méthode, pour obtenir le mot de passe d'origine de la base de données rendant l'autorisation de digestion impossible. –
10
Un hachage des informations d'identification est envoyé sur le réseau.
HA1 = MD5(username:realm:password)
+0
du client au serveur?Pourriez-vous s'il vous plaît fournir des étapes pour l'interaction? L'article de Wikipedia est bon mais j'ai besoin d'une meilleure explication ou d'un exemple. – SoftwareGeek
+0
Oui, le client génère la valeur de hachage et l'envoie au serveur. L'article de Wikipédia décrit le protocole en détail, je vous suggère de le consulter pour plus d'informations. –
1
La seule façon d'obtenir le hachage HA1 des informations d'identification est de connaître le mot de passe. Le serveur connaît HA1 mais pas le mot de passe qui l'a généré. Si HA1 était connu d'un attaquant, il pourrait entrer dans le système. Donc, il n'est pas envoyé sur le fil. Un hachage supplémentaire basé sur nonce, etc. est fait avant de faire ceci, et ceci doit concorder avec un calcul similaire effectué sur le serveur. Ainsi, tant que le serveur garde HA1 privé, le système est sécurisé.
+0
Ceci est l'explication de l'authentification Digest, où le mot de passe n'est pas envoyé en texte brut (ce qui est le cas pour l'authentification de base) –
Grande explication par @Gumbo ici: http://stackoverflow.com/a/5288679/591487 – inorganik
Quelque chose que vous ne devriez jamais utiliser. Ne protège pas le mot de passe en transit et nécessite que le serveur stocke les mots de passe en clair. – CodesInChaos
Digest fournit une meilleure sécurité en transit que l'authentification de base pour le trafic _unencrypted_, mais il est faible. Il est BEAUCOUP plus sûr d'utiliser Basic auth en combinaison avec SSL/TLS à la place, car de cette façon vous pouvez également garder les mots de passe sur le serveur cryptés. – rustyx