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 des informations d'identification de manière encrypté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.

Alors que l'authentification de base utilise un encodage base64 non-encrypté.

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 assurée, comme dans le cas du protocole https.

Consultez RFC-2617 pour tous les détails sanglants.

Answer 2

Authentification d'accès de base HTTP

• ÉTAPE 1 : le client envoie une requête 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 l'encodage base64 (pas de chiffrement) pour générer notre chaîne cryptographique qui contient les informations du nom d'utilisateur et du mot de passe. L'Authentification de base n'a pas besoin d'être implémentée via SSL, mais si vous ne le faites pas, elle n'est pas du tout sécurisée. Donc je ne vais même pas envisager l'idée de l'utiliser sans.

Avantages :

• Il est simple à implémenter, donc vos développeurs clients auront moins de travail à faire et prendront moins de temps pour livrer, ce qui pourrait encourager les développeurs à 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 les méthodes d'authentification plus complexes pourraient l'être

Inconvénients :

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

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

Syntaxe de l'authentification de base

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

Authentification d'accès de base HTTP Digest
L'Authentification d'accès de base 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 de base HTTP Digest 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 particulière, 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 cryptée du nom d'utilisateur, du mot de passe et du royaume (un hash)
• ÉTAPE 4 : le serveur répond avec les informations demandées si le hash client correspond à leur propre hash du nom d'utilisateur, mot de passe et royaume, ou une erreur sinon

Avantages :

• Aucun nom d'utilisateur ou mot de passe n'est envoyé 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 via SSL. Cela signifie que SSL n'est pas requis, 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 HTTP Basic
• 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 chiffrement de mot de passe fort, ce qui signifie que les mots de passe stockés sur le serveur pourraient être piratés

En Résumé, l'Authentification HTTP Digest est intrinsèquement vulnérable à au moins deux attaques, alors qu'un serveur utilisant un chiffrement fort pour les mots de passe avec le HTTP de base via SSL est moins susceptible de partager ces vulnérabilités.

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

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

Hash1=MD5(nom_utilisateur:royaume:mot_de_passe)
Hash2=MD5(méthode:URI_de_digest)
réponse=MD5(Hash1:nonce:Hash2)

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

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

source et exemple

Dans Postman, cela ressemble à ceci :

Remarque :

• Les schémas de base et digest sont dédiés à l'authentification en utilisant un nom d'utilisateur et un secret.
• Le schéma de l'emporteur est dédié à l'authentification en utilisant un jeton. Dans l'en-tête de BA (Authentification de base), le jeton du porteur peut être considéré comme donner accès au porteur de ce jeton.

Answer 3

Comparons la différence entre les deux méthodes d'authentification HTTP en utilisant Wireshark (outil d'analyse des paquets envoyés ou reçus).

1. Authentification basique HTTP

Dès que le client tape le nom d'utilisateur: mot de passe correct, tel que demandé par le serveur Web, le serveur Web vérifie dans la base de données si les informations d'identification sont correctes et donne l'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: mot de passe étaient corrects.

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

2. Authentification Digest HTTP (rfc 2069)

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

Voici les paquets montrant les demandes faites par le client et les réponses du serveur.

Dès que le client tape les informations requises 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 l'accès à la ressource, sinon une erreur 401.

Dans le Authorization ci-dessus, la chaîne de response est calculée en utilisant les valeurs de Username,Realm,Password,http-method,URI et Nonce comme indiqué dans l'image :

(les deux-points sont inclus)

Ainsi, nous pouvons voir que l'Authentification Digest est plus sécurisée car elle implique un hachage (chiffrement MD5), de sorte que les outils de capture de paquets ne peuvent pas intercepter le mot de passe même si dans l'Authentification de base, le mot de passe exact était affiché sur Wireshark.

Answer 4

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

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