Qu'est-ce que l'authentification Digest?
En quoi l'authentification Digest diffère-t-elle de l'authentification de base, à part l'envoi d'informations d'identification sous forme de texte brut?
La principale différence est qu’il n’est pas nécessaire d’envoyer le nom d’utilisateur et le mot de passe en texte clair. Il est également immunisé contre les attaques par rejeu, car il utilise un numéro unique du serveur.
Le serveur attribue 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 requête 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. Au lieu d'utiliser le mot de passe saisi dans le navigateur, le serveur recherche le mot de passe attendu pour l'utilisateur dans son DB utilisateur. Il recherche le mot de passe stocké pour ce nom d'utilisateur, utilise le même algorithme et le compare à ce que le client a envoyé. S'ils correspondent, l'accès est autorisé, 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 normalisée dans la RFC2617 . Il y a un belle vue d'ensemble sur Wikipedia :
Vous pouvez penser comme ça:
- 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 (nom d'utilisateur, domaine, generate_md5_key (nonce, nom d'utilisateur, domaine, URI, password_given_by_user_to_browser)) (oui, c'est très simplifié)
- Le serveur prend nom d'utilisateur et domaine (plus il connaît l'URI demandée par le client) et il recherche le mot de passe pour ce nom d'utilisateur. Ensuite, il lance sa propre version de generate_md5_key (nonce, nom d'utilisateur, domaine, URI, mot_de_passe_I_have_pour_cette_utilisateur_in_moi_db)
- Il compare la sortie de generate_md5 () qu'il a obtenue avec celle envoyée par le client, si elles correspondent si le client a envoyé le mot de passe correct. S'ils ne correspondent pas, le mot de passe envoyé était incorrect.
Un hachage des informations d'identification est envoyé sur le fil.
HA1 = MD5(username:realm:password)
Le seul moyen 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 l'attaquant connaissait HA1, il pourrait entrer dans le système. Donc, il n'est pas envoyé sur le fil. Un autre hachage basé sur nonce, etc. est effectué avant, ce qui doit correspondre à un calcul similaire effectué sur le serveur. Ainsi, tant que le serveur garde HA1 confidentiel, le système est sécurisé.