Qu'est-ce que l'authentification Digest?

101

En quoi l'authentification Digest diffère-t-elle de l'authentification de base autre que l'envoi d'informations d'identification sous forme de texte brut?

digest-authentication

— LogicielGeek
source

Excellente explication par @Gumbo ici: 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 oblige le serveur à stocker les mots de passe en clair.

— CodesInChaos du

Digest offre une meilleure sécurité en transit que l'authentification de base pour le trafic non chiffré , mais elle est faible. Il est BEAUCOUP plus sûr d'utiliser l'authentification de base 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

Réponses:

179

La principale différence est qu'il ne nécessite pas l'envoi du nom d'utilisateur et du mot de passe sur le fil en texte brut. Il est également immunisé contre les attaques par rejeu, car il utilise un numéro unique du serveur.

Le serveur donne au client un numéro à usage 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 royaume pour tenter de s'authentifier.

Côté serveur, la même méthode est utilisée pour générer une clé de hachage, mais au lieu d'utiliser le mot de passe saisi 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, passe par le même algorithme et le compare à ce que le client a envoyé. S'ils correspondent, l'accès est accordé, sinon il peut renvoyer un 401 non autorisé (pas de connexion ou échec de connexion) ou un 403 interdit (accès refusé).

L'authentification Digest est normalisée dans la RFC2617 . Il y en a un bel aperçu sur Wikipedia :

Vous pouvez y penser comme ceci:

Le client fait la demande
Le client récupère un nonce du serveur et une demande d'authentification 401
Le client renvoie le tableau de réponses suivant (username, realm, generate_md5_key (nonce, username, realm, URI, password_given_by_user_to_browser)) (oui, c'est très simplifié)
Le serveur prend le nom d'utilisateur et le domaine (plus il connaît l'URI que le client demande) et il recherche le mot de passe pour ce nom d'utilisateur. Ensuite, il va et fait sa propre version de generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
Il compare la sortie de generate_md5 () qu'il a obtenue avec celle que le client a envoyée, si elles correspondent au client qui a envoyé le mot de passe correct. S'ils ne correspondent pas, le mot de passe envoyé était erroné.

— Ian C.
source

Belle explication. Le nom d'utilisateur et le pwd sont-ils pour un utilisateur Windows? D'où sont-ils générés?

— SoftwareGeek

Ils correspondent à 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. Il est fort probable que ce soit quelque chose de spécifique à cette application Web et non à votre mot de passe Windows. Cela dépend beaucoup de la façon dont l'application Web est conçue.

— Ian C.

Cette réponse a 6 ans, mais je suppose que tous les systèmes sensibles à la sécurité stockent les mots de passe dans un format de hachage salé maintenant. Il n'y a pas, et il ne devrait pas y en avoir, de méthode pour obtenir le mot de passe d'origine de la base de données, ce qui rend l'autorisation de résumé impossible.

— Ramon de Klein

Si le hachage condensé du nom d'utilisateur et du mot de passe est stocké dans la base de données au lieu des mots de passe simples, il est toujours possible d'utiliser digest auth @RamondeKlein

— karakays

@BlueBockser Je pense que karakays signifiait qu'au lieu d'utiliser un mot de passe simple, un hachage résultant de la combinaison du nom d'utilisateur et de son mot de passe devrait être stocké sur le serveur lors de l'inscription et calculé côté client avant l'authentification. Cela peut également être fait avec un simple hachage du mot de passe.

— logo_writer

Un hachage des informations d'identification est envoyé sur le fil.

HA1 = MD5(username:realm:password)

Wikipedia a un excellent article sur ce sujet

— Philippe Fourie
source

du client au serveur? Pourriez-vous s'il vous plaît indiquer les étapes de l'interaction? L'article Wikipedia est bon mais j'ai besoin d'une meilleure explication ou d'un meilleur exemple.

— SoftwareGeek

Oui, le client génère la valeur de hachage et l'envoie au serveur. L'article Wikipédia décrit le protocole en détail, je vous suggère de vous y référer pour plus d'informations.

— Philip Fourie

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 effectué avant de faire cela, et cela doit concorder avec un calcul similaire effectué sur le serveur. Ainsi, tant que le serveur garde HA1 privé, le système est sécurisé.

— Chris Oakley
source

C'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)

— Erik Oppedijk