Quelle est la différence entre Digest et Basic Authentication?

authentification HTTP Basic Access

• étape 1 : le client fait une demande d'information, en envoyant un nom d'utilisateur et mot de passe au serveur en clair
• l'ÉTAPE 2 : le serveur répond avec l'information désirée ou une erreur

base64 encoding (not cryptage) pour générer notre chaîne cryptographique qui contient les informations de nom d'utilisateur et de mot de passe. HTTP Basic n'a pas besoin d'être implémenté sur SSL, mais si vous ne le faites pas, il n'est pas du tout sécurisé. Donc, je ne vais même pas à l'idée de l'utiliser sans.

Pour:

• C'est simple à mettre en œuvre, de sorte que vos développeurs clients auront moins de travail à faire et prendre moins de temps à livrer, de sorte que les développeurs pourraient être plus susceptible de vouloir utiliser votre API
• contrairement à Digest, vous pouvez stocker les mots de passe sur le serveur dans n'importe quelle méthode de cryptage que vous aimez, comme bcrypt, ce qui rend les mots de passe plus sûr
• un seul appel au serveur est nécessaire pour obtenir l'information, ce qui rend le client légèrement plus rapide que les méthodes d'authentification plus complexes pourraient être

Inconvénients:

• SSL est plus lent à exécuter que le HTTP de base, donc les clients sont un peu 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 de sécurité

En résumé – si vous avez le contrôle des clients, ou pouvez vous assurer qu'ils utilisent SSL, HTTP Basic est un bon choix. La lenteur de la SSL peut être annulée par la vitesse de une seule demande

syntaxe d'authentification de base

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

authentification D'accès par HTTP Digest

L'authentification d'accès Digest utilise le hachage (I. e digest signifie "couper en petits morceaux") méthodes pour générer le résultat cryptographique. L'authentification HTTP Digest access est une forme plus complexe d'authentification qui fonctionne comme suit:

• ÉTAPE 1 : un client envoie une requête à un serveur
• STEP 2 : le serveur répond avec un code spécial (appelé nonce i.e. n umber used only once ), une autre chaîne représentant le "1519710920 realm 1519660920" (un hash) et demande le client à authentifier
• ETAPE 3 : le client répond avec ce nonce et une version cryptée du nom d'utilisateur, du mot de passe et du domaine (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, mot de passe et domaine, ou une erreur sinon

Pour:

• Pas de noms d'utilisateur ou des mots de passe sont envoyés au serveur en clair, ce qui rend une connexion non-SSL plus sûre qu'une requête HTTP de base qui n'est pas envoyée via SSL. Cela signifie que SSL n'est pas nécessaire, ce qui rend chaque appel un peu plus rapide

Inconvénients:

• pour chaque appel nécessaire, le client doit faire 2, ce qui rend le processus légèrement plus lent que HTTP Basic
• HTTP Digest est vulnérable à un homme-dans-le-milieu attaque de sécurité qui signifie essentiellement qu'il pourrait être piraté
• HTTP Digest empêche l'utilisation du cryptage de mot de passe fort, ce qui signifie que les mots de passe stockés sur le serveur pourrait être piraté

en résumé , HTTP Digest est intrinsèquement vulnérable à au moins deux attaques, alors qu'un serveur utilisant un cryptage fort pour les mots de passe avec HTTP Basic over SSL est moins susceptible de partager ces vulnérabilités.

si vous n'avez pas le contrôle sur vos clients, cependant ils pourraient tenter d'effectuer l'authentification de base sans SSL, qui est beaucoup moins sûr que Digest.

RFC 2069 Digest Access Authentication syntaxe

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

RFC 2617 Digest Access Authentication syntaxe

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

source et exemple

En Facteur se présente comme suit:

voyons la différence entre les deux HTTP authentification utilisant Wireshark (outil pour analyser les paquets envoyés ou reçus) .

1. Authentification Http Basic

dès que le type de client dans le correct nom d'utilisateur: mot de passe ,comme demandé par le serveur Web, le Le serveur web vérifie dans la base de données si les informations d'identification sont correctes 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 ,I. e, le nom d'utilisateur: mot de passe étaient corrects .

maintenant, dans l'en-tête Authorization il montre qu'il est de base autorisation suivie d'une certaine chaîne aléatoire .Cette chaîne de caractères est la encodée (Base64) version des lettres de créance admin:aadd (y compris colon).

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 clair sur le réseau .Mais L'Autorité de Digest envoie un hachage du mot de passe en utilisant l'algorithme de hachage.

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

dès que le client tape les informations d'identification demandées par le serveur , le mot de passe est converti en response à l'aide d'un algorithme et est ensuite envoyé au serveur , si la base de données du serveur a la même réponse que celle donnée par le client que le serveur donne l'accès à la ressource , sinon une erreur 401 .

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

(les colons sont inclus)

par conséquent, nous pouvons voir que L'authentification Digest est plus sûre car elle implique le hachage (cryptage MD5), de sorte que les outils de paquet sniffer ne peut pas renifler le mot de passe bien que dans L'Auth de base le mot de passe exact a été montré sur Wireshark.