Quelle est la différence entre l'authentification Digest et l'authentification de base?

Question

Quelle est la différence entre l'authentification Digest et l'authentification Basic ?

Answer 1

L'authentification Digest communique les informations d'identification sous forme cryptée en appliquant une fonction de hachage à : le nom d'utilisateur, le mot de passe, une valeur de nonce fournie par le serveur, la méthode HTTP et l'URI demandée.

Tandis que l'authentification de base utilise un encodage base64 non crypté.

Par conséquent, l'authentification de base ne devrait généralement être utilisée que lorsque la sécurité de la couche de transport est fournie, comme dans le cas de https.

Consultez RFC-2617 pour tous les détails.

Answer 2

Authentification d'accès de base HTTP

• ÉTAPE 1 : le client envoie une demande d'informations, en envoyant un nom d'utilisateur et un mot de passe au serveur en texte clair
• ÉTAPE 2 : le serveur répond avec les informations souhaitées ou une erreur

L'Authentification de base utilise un encodage base64 (pas de cryptage) pour générer notre chaîne cryptographique qui contient les informations de nom d'utilisateur et de mot de passe. L'authentification de base HTTP n'a pas besoin d'être implémentée sur SSL, mais si ce n'est pas le cas, elle n'est pas du tout sécurisée. Donc, je ne vais même pas envisager de l'utiliser sans.

Avantages :

• C'est simple à mettre en œuvre, donc vos développeurs clients auront moins de travail à faire et mettront moins de temps à livrer, donc les développeurs seront plus susceptibles de vouloir utiliser votre API
• Contrairement à Digest, vous pouvez stocker les mots de passe sur le serveur dans la méthode de cryptage de votre choix, comme bcrypt, rendant les mots de passe plus sécurisés
• Un seul appel au serveur est nécessaire pour obtenir les informations, rendant le client légèrement plus rapide que ce que pourraient être des méthodes d'authentification plus complexes

Inconvénients :

• SSL est plus lent à exécuter que le basique HTTP donc cela rend les clients légèrement plus lents
• Si vous n'avez pas le contrôle des clients et ne pouvez pas forcer le serveur à utiliser SSL, un développeur pourrait ne pas utiliser SSL, causant un risque pour la sécurité

En Résumé - si vous avez le contrôle des clients, ou pouvez garantir qu'ils utilisent SSL, l'authentification de base HTTP est un bon choix. La lenteur de la SSL peut être compensée par la vitesse de ne faire qu'une seule requête

Syntaxe de l'authentification de base

Valeur = nom_utilisateur:mot_de_passe
Valeur Encodée = base64(Valeur)
Valeur d'authentification = Basic  
// enfin, la clé/valeur d'authentification est ajoutée à l'en-tête http comme suit
Autorisation: 

Authentification d'accès Digest HTTP
L'Authentification d'accès Digest utilise les méthodologies de hachage (c'est-à-dire que digest signifie découper en petits morceaux) pour générer le résultat cryptographique. L'authentification d'accès Digest HTTP est une forme d'authentification plus complexe qui fonctionne comme suit :

• ÉTAPE 1 : un client envoie une requête à un serveur
• ÉTAPE 2 : le serveur répond avec un code spécial (appelé un nonce c'est-à-dire un nombre utilisé une seule fois), une autre chaîne représentant le royaume (pas une page spécifique, cela pourrait être un groupe de pages c'est-à-dire un espace de protection partitionné) et demande au client de s'authentifier
• ÉTAPE 3 : le client répond avec ce nonce et une version chiffrée du nom d'utilisateur, du mot de passe et du royaume (un hachage)
• ÉTAPE 4 : le serveur répond avec les informations demandées si le hachage du client correspond à leur propre hachage du nom d'utilisateur, du mot de passe et du royaume, ou une erreur sinon

Avantages :

• Aucun nom d'utilisateur ni mot de passe ne sont envoyés au serveur en texte clair, rendant une connexion non-SSL plus sécurisée qu'une requête de base HTTP qui n'est pas envoyée sur SSL. Cela signifie que SSL n'est pas nécessaire, ce qui rend chaque appel légèrement plus rapide.

Inconvénients :

• Pour chaque appel nécessaire, le client doit en faire 2, rendant le processus légèrement plus lent que celui de l'authentification de base HTTP
• HTTP Digest est vulnérable à une attaque de sécurité de type homme du milieu, ce qui signifie essentiellement qu'il pourrait être piraté
• HTTP Digest empêche l'utilisation du cryptage fort des mots de passe, ce qui signifie que les mots de passe stockés sur le serveur pourraient être piratés

En Résumé, l'authentification de Digest est intrinsèquement vulnérable à au moins deux attaques, alors qu'un serveur utilisant un cryptage fort pour les mots de passe avec l'authentification de base HTTP sur SSL est moins susceptible de présenter ces vulnérabilités.

Si vous n'avez pas le contrôle sur vos clients, cependant, ils pourraient tenter de réaliser une authentification de base sans SSL, ce qui est beaucoup moins sécurisé que Digest.

Syntaxe de l'Authentification d'accès Digest RFC 2069

Hach1=MD5(nom_utilisateur:royaume:mot_de_passe)
Hach2=MD5(méthode:URI_de_digest)
réponse=MD5(Hach1:nonce:Hach2)

Syntaxe de l'Authentification d'accès Digest RFC 2617

Hach1=MD5(nom_utilisateur:royaume:mot_de_passe)
Hach2=MD5(méthode:URI_de_digest)
réponse=MD5(Hach1:nonce:nombre_de_nonce:cnonce:qop:Hach2)
//quelques paramètres supplémentaires ajoutés 

source et exemple

Dans Postman cela se présente comme suit :

Note :

• Les schémas Basic et Digest sont dédiés à l'authentification en utilisant un nom d'utilisateur et un secret.
• Le schéma Bearer est dédié à l'authentification en utilisant un jeton. Dans l'entête de l'authentification de base, le jeton Bearer peut être considéré comme donnant accès au porteur de ce jeton.

Answer 3

Découvrons la différence entre les deux authentifications HTTP en utilisant Wireshark (outil d'analyse des paquets envoyés ou reçus).

1. Authentification HTTP de base

Dès que le client saisit le nom d'utilisateur: mot de passe correct, demandé par le serveur Web, le serveur Web vérifie dans la base de données si les identifiants sont corrects et donne accès à la ressource.

Voici comment les paquets sont envoyés et reçus :

Dans le premier paquet, le client remplit les informations d'identification en utilisant la méthode POST à la ressource - lab/webapp/basicauth. En retour, le serveur répond avec le code de réponse http 200 ok, c'est-à-dire que le nom d'utilisateur et le mot de passe étaient corrects.

Maintenant, dans l'en-tête Authorization, il montre qu'il s'agit d'une autorisation Base suivie d'une chaîne aléatoire. Cette chaîne est la version encodée (Base64) des informations d'identification admin:aadd (en incluant le deux-points).

2. Authentification HTTP Digest (rfc 2069)

Jusqu'à présent, nous avons vu que l'Authentification de Base envoie nom d'utilisateur: mot de passe en texte clair sur le réseau. Mais le Digest Auth envoie un HASH du mot de passe en utilisant un algorithme de hachage.

Voici les paquets montrant les requêtes faites par le client et les réponses du serveur.

Dès que le client entre les informations d'identification demandées par le serveur, le mot de passe est converti en une réponse en utilisant un algorithme puis est envoyé au serveur. Si la base de données du serveur a la même réponse que celle donnée par le client, le serveur donne accès à la ressource, sinon une erreur 401.

Dans l'en-tête Authorization ci-dessus, la chaîne de réponse est calculée en utilisant les valeurs de Nom d'utilisateur, Realm, Mot de passe, méthode http, URI et Nonce comme montré dans l'image :

(les deux-points sont inclus)

Ainsi, nous pouvons voir que l'Authentification Digest est plus sécurisée car elle implique du hachage (chiffrage MD5), de sorte que les outils de capture de paquets ne peuvent pas intercepter le mot de passe alors que dans l'Authentification de Base, le mot de passe exact était visible sur Wireshark.

Answer 4

L'authentification de base utilise le codage base 64 Encoding pour générer une chaîne cryptographique contenant les informations de nom d'utilisateur et de mot de passe.

L'authentification par accès digest utilise des méthodologies de hachage pour générer le résultat cryptographique