Quelle est la différence entre l'authentification Digest et l'authentification de base?
Quelle est la différence entre Digest et Basic Authentification?
L'authentification Digest communique les informations d'identification sous une forme cryptée en appliquant une fonction de hachage au nom d'utilisateur, au mot de passe, à la valeur nonce fournie par le serveur, à la méthode HTTP et à l'URI demandé.
Alors que l'authentification de base utilise un codage base64 non chiffré.
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, telle que https.
Voir RFC-2617 pour tous les détails sanglants.
Authentification d'accès HTTP de base
- ÉTAPE 1: le client demande une information en envoyant un nom d'utilisateur et un mot de passe au serveur en texte brut
- ÉTAPE 2: le serveur répond avec les informations souhaitées ou une erreur
L'authentification de base utilise un codage base64 pour générer notre chaîne cryptographique contenant 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 l’utilisez pas, il n’est pas sécurisé du tout. Donc, je ne vais même pas envisager l'idée de l'utiliser sans.
Avantages:
- Il est simple à mettre en œuvre, de sorte que les développeurs de votre client auront moins de travail à faire et prendront moins de temps à livrer. Par conséquent, les développeurs pourraient être plus enclins à utiliser votre API.
- Contrairement à Digest, vous pouvez stocker les mots de passe sur le serveur avec la méthode de cryptage de votre choix, telle que bcrypt, pour renforcer la sécurité des mots de passe.
- Un seul appel au serveur est nécessaire pour obtenir les informations, ce qui rend le client légèrement plus rapide que des méthodes d'authentification plus complexes.
Inconvénients:
- L'exécution de SSL est plus lente que celle du HTTP de base, ce qui ralentit légèrement le traitement des clients.
- Si vous n’avez pas le contrôle des clients et ne pouvez pas forcer le serveur à utiliser SSL, un développeur peut ne pas utiliser SSL, ce qui pose 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, HTTP Basic est un bon choix. La lenteur du SSL peut être annulée par la vitesse à laquelle vous ne faites qu'une requête.
Syntaxe de l'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 HTTP Digest
L’authentification Digest Access utilise les méthodes de hachage (c.-à-d., Digérer, couper en petits morceaux) pour générer le résultat cryptographique. L'authentification d'accès HTTP Digest est une forme d'authentification plus complexe qui fonctionne comme suit:
- ÉTAPE 1: un client envoie une demande à un serveur
- ÉTAPE 2: le serveur répond avec un code spécial (appelé un nonce c'est-à-dire n umber utilisé seulement une fois ), une autre chaîne représentant le royaume ) (un hachage) 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 domaine (un hachage)
- ÉTAPE 4: le serveur répond avec les informations demandées si le hachage du client correspond à son propre hachage du nom d'utilisateur, du mot de passe et du domaine, ou une erreur si ce n'est pas le cas.
Avantages:
- Aucun nom d'utilisateur ou mot de passe n'est envoyé au serveur en texte brut, ce qui rend une connexion non-SSL plus sécurisée qu'une demande HTTP Basic qui n'est pas envoyée via SSL. Cela signifie que SSL n’est pas obligatoire, ce qui accélère légèrement chaque appel.
Inconvénients:
- Pour chaque appel nécessaire, le client doit effectuer 2, ce qui rend le processus légèrement plus lent que HTTP Basic.
- HTTP Digest est vulnérable à une attaque de la sécurité par un homme du milieu qui signifie 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é, 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 sur SSL est moins susceptible de partager ces vulnérabilités.
Si vous n’avez pas le contrôle de vos clients, ils peuvent toutefois tenter d’effectuer une authentification de base sans SSL, qui est beaucoup moins sécurisé que Digest.
Syntaxe d'authentification d'accès Digest RFC 2069
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)
Syntaxe d'authentification d'accès Digest RFC 2617
Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added
Dans Postman ressemble à ceci:
Remarque:
- Les Schémas de base et Digest sont dédiés à l'authentification à l'aide d'un nom d'utilisateur et d'un secret.
- Le schéma de support est dédié à l'authentification à l'aide d'un jeton.
Voyons la différence entre les deux [~ # ~] authentifications http [~ # ~] à l'aide de Wireshark (outil d'analyse des paquets envoyé ou reçu).
1. Authentification de base HTTP
Dès que le client tape le nom d'utilisateur correct : mot de passe , comme demandé par le serveur Web, le serveur Web vérifie dans la base de données si les informations d'identification 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 à l'aide de la méthode [~ # ~] post [~ # ~] de 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 était correct.
Dans l'en-tête Authorization, il est indiqué qu'il s'agit d'une autorisation de base suivie d'une chaîne aléatoire. Cette chaîne est la version codée (Base64) des informations d'identification admin:aadd (y compris les deux points).
2. Authentification Digest Http (RFC 2069)
Jusqu'ici, nous avons vu que l'authentification de base envoie nom d'utilisateur: mot de passe en texte clair sur le réseau .Mais l'authentification abrégée envoie un [~ # ~] hash [~ # ~] du mot de passe utilisant l'algorithme de hachage.
Voici les 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, puis 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 ce qui précède Authorization, la chaîne response est calculée à l'aide des valeurs de Username, Realm, Password, http-method, URI et Nonce comme indiqué dans l'image:
(les deux points sont inclus)
Par conséquent, nous pouvons voir que l'authentification Digest est plus sécurisée car elle implique un hachage (cryptage MD5). Par conséquent, les outils de détection de paquets ne peuvent pas renifler le mot de passe, même si dans Basic Auth, le mot de passe exact était affiché sur Wireshark.
Utilisation de base de l’authentification de base 64 Encodage 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 les méthodologies de hachage pour générer le résultat cryptographique.