Quelle est la différence entre Digest et Authentification de base?


Réponses:


195

L'authentification Digest communique les informations d'identification sous une forme chiffrée en appliquant une fonction de hachage à: le nom d'utilisateur, le mot de passe, une 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 doit 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.


1
comment l'authentification de base n'est pas cryptée? J'ai utilisé ce site Web pour décoder les données de nom d'utilisateur et de mot de passe base64decode.org
Dot Freelancer

65
L'encodage et le cryptage ne sont pas la même chose. Le fait que vous puissiez décoder les informations d'identification à l'aide de ce site montre qu'elles ne sont pas cryptées.
Andy

@Andy Y a-t-il une différence entre l'authentification Digest et l'authentification cryptographique? Ou font-ils référence à la même chose? Merci.
user224567893

1
@Andy qu'entendez-vous par "décoder les informations d'identification"? Les informations d'identification hachées ne peuvent pas être décodées ...
Alexander Suraphel

8
Bien, et l'authentification de base n'utilise pas les informations d'identification hachées, elles sont encodées en base64.
Andy

111

Authentification d'accès de base HTTP

  • ÉTAPE 1 : le client fait une demande d'informations 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 le codage base64 (pas le cryptage) pour générer notre chaîne cryptographique qui contient les informations du nom d'utilisateur et du mot de passe. HTTP Basic n'a pas besoin d'être implémenté via SSL, mais si vous ne le faites pas, il n'est pas du tout sécurisé. Je ne vais donc même pas envisager l'idée de l'utiliser sans.

Avantages:

  • Il est simple à mettre en œuvre, de sorte que vos développeurs clients auront moins de travail à faire et prendront moins de temps à livrer, de sorte que les développeurs pourraient être 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 que vous souhaitez, telle que bcrypt, ce qui rend les mots de passe plus sécurisés
  • Un seul appel au serveur est nécessaire pour obtenir les informations, ce qui rend le client légèrement plus rapide que les méthodes d'authentification plus complexes.

Les inconvénients:

  • SSL est plus lent à exécuter que HTTP de base, ce qui ralentit légèrement les clients
  • Si vous ne contrôlez pas les 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 contrôlez les 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 de faire une seule demande

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 HTTP Digest Access L'authentification
Digest Access utilise les méthodes de hachage (c'est-à-dire les moyens de résumé coupés 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éie n umber utilisé une seule 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 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 client correspond à leur propre hachage du nom d'utilisateur, du mot de passe et du domaine, ou une erreur sinon

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 requis, ce qui rend chaque appel légèrement plus rapide

Les 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 sécurité par l'homme du milieu, ce qui signifie 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 pourraient être piratés

En résumé , HTTP Digest est intrinsèquement vulnérable à au moins deux attaques, tandis 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 de contrôle sur vos clients, ils pourraient cependant tenter d'authentifier Basic sans SSL, ce qui est beaucoup moins sécurisé que Digest.

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

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

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

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

source et exemple

Dans Postman ressemble à ceci:

entrez la description de l'image ici

Remarque:

  • Les schémas Basic et Digest sont dédiés à l'authentification à l'aide d'un nom d'utilisateur et d'un secret.
  • Le schéma Bearer est dédié à l'authentification à l'aide d'un jeton.

1
Sur votre serveur Web, ne pourriez-vous pas simplement rediriger vers https pour toutes les requêtes http même si vous n'avez aucun contrôle sur les clients?
10cool

Plus j'y pense plus je vois votre point cependant. En supposant qu'ils soumettent leurs informations d'identification via http et accèdent à votre site, vous pouvez rediriger, mais s'ils frappent un site malveillant, vous ne pouvez pas aider.
10cool

3
Pourquoi, avec Digest, ne pouvez-vous pas chiffrer votre mot de passe avant de le stocker dans la base de données, et lorsque vous le retirez, le déchiffrer?
papiro

Bien que la réponse choisie soit plus proche de la question, j'aime cette réponse car elle nous donne des avantages et des inconvénients pour les non-initiés.
coder0h1t

1
@ 10cool une fois que vous avez accédé au site Web avec http, il est trop tard ... malheureusement. l'utilisateur: pass a déjà été envoyé en clair sur le fil, même si vous êtes redirigé vers httpS juste après.
Julien

41

Voyons la différence entre les deux authentifications HTTP à l' aide de Wireshark(Outil pour analyser les paquets envoyés ou reçus).

1. Authentification de base Http

De base

Dès que le client saisit le bon nom d'utilisateur: 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 correctes et donne accès à la ressource.

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

entrez la description de l'image ici 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 en retour avec le code de réponse http 200 ok , c'est-à-dire que le nom d'utilisateur: mot de passe était correct.

Détail du paquet HTTP

Maintenant, dans l'en- Authorizationtête, il indique 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'à présent, nous avons vu que l'authentification de base 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 l'algorithme de hachage.

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

Digérer

Dès que le client tape les informations d'identification demandées par le serveur, le mot de passe est converti en un à l' responseaide d'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 .

Paquet d'authentification détaillé Dans ce qui précède Authorization, la responsechaîne est calculée en utilisant les valeurs de Username, Realm, Password, http-method, URIet Noncecomme montré dans l'image:

Algorithme de réponse (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 (chiffrement MD5), donc les outils de renifleur de paquets ne peuvent pas renifler le mot de passe bien que dans Basic Auth le mot de passe exact ait été affiché sur Wireshark.


6
Cela devrait être la réponse acceptée car elle est plus informative et bravo pour les graphiques.
mak

Mais dans Wireshark, vous ne reniflez que des paquets en utilisant le protocole http? Et si vous utilisiez le protocole https?
JohnRDOrazio

Wirehark ne décide pas s'il doit renifler Http ou Https. Ce sont les serveurs Web qui sont configurés avec des protocoles.
BoRRis

1
Absurdité. L'authentification de base est uniquement destinée à être utilisée via HTTPS. La vraie comparaison est donc l'authentification de base sur HTTPS et l'authentification de résumé sur HTTP. Étant donné que les sites Web chiffrent tout leur trafic de nos jours, vous pouvez aussi utiliser Basic Auth sur HTTPS.
Gili

-3

L'authentification de base utilise l' encodage de base 64 pour générer une chaîne cryptographique qui contient les informations du nom d'utilisateur et du mot de passe.

L'authentification Digest Access utilise les méthodologies de hachage pour générer le résultat cryptographique


1
le codage base 64 n'est pas cryptographique.
Thomas Sobieck
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.