À quoi sert un nonce client?

Question

Après avoir lu la première partie du livre de Ross Anderson, Ingénierie de la sécurité , et clarifié certains sujets sur Wikipédia, je suis tombé sur l'idée de Client Nonce (cnonce). Ross ne le mentionne jamais dans son livre et j'ai du mal à comprendre l'objectif qu'il sert dans l'authentification des utilisateurs.

Un nonce normal est utilisé pour éviter les attaques de relecture qui impliquent l'utilisation d'une réponse expirée pour obtenir des privilèges. Le serveur fournit au client un nonce (Number used ONCE) que le client est obligé d'utiliser pour hacher sa réponse, le serveur hache ensuite la réponse qu'il attend avec le nonce qu'il a fourni et si le hachage du client correspond au hachage du serveur, le serveur peut vérifier que la demande est valide et fraîche. C'est tout ce qu'il vérifie; valide et frais .

Les explications que j'ai trouvées pour un client nonce sont cependant moins simples et discutables. La page Wikipedia pour l'authentification d'accès numérique et plusieurs réponses ici sur Stackoverflow semblent suggérer qu'un nonce client est utilisé pour éviter les attaques en texte clair choisi. J'ai plusieurs problèmes avec cette idée:

Si une personne peut renifler et insérer des paquets, la plus grande vulnérabilité est une attaque de l'homme du milieu que ni un nonce ni un cnonce ne peuvent surmonter, rendant ainsi les deux sans signification.
En supposant une seconde que l'attaquant ne souhaite pas s'engager dans une attaque par l'homme du milieu et souhaite récupérer les détails de l'authentification, comment un cnonce fournit-il une protection supplémentaire? Si l'attaquant intercepte la communication et répond à une demande avec son propre nonce, la réponse du client sera un hachage du nonce, des données et de cnonce en plus du cnonce sous forme non chiffrée. L'attaquant a maintenant accès au nonce, cnonce et au hachage. L'attaquant peut désormais hacher ses tables Rainbow avec le nonce et le cnonce et trouver une correspondance. Par conséquent, le cnonce fournit zéro protection supplémentaire.

Alors, quel est le but d'une cnonce?

Je suppose qu'il y a une partie de l'équation que je ne comprends pas, mais je n'ai pas encore trouvé d'explication pour cette partie.

EDIT Certaines réponses suggèrent que le client peut fournir un nonce et cela servira le même but. Cela brise cependant le modèle défi-réponse, quelles en sont les implications?

Thomas Pornin · Accepted Answer

Un nonce est une valeur unique choisie par une entité dans un protocole, et il est utilisé pour protéger cette entité contre les attaques qui tombent sous le très grand parapluie de "rejouer".

Par exemple, envisagez un protocole d'authentification basé sur un mot de passe qui se présente comme suit:

le serveur envoie un "challenge" (une valeur supposée aléatoire c ) au client
le client doit répondre en envoyant h (c || p) où h est une fonction de hachage sécurisée (par exemple SHA-256), p est le mot de passe utilisateur, et ' || 'indique la concaténation
le serveur recherche le mot de passe dans sa propre base de données, recalcule la réponse attendue du client et voit s'il correspond à ce que le client a envoyé

Les mots de passe sont des valeurs secrètes qui s'inscrivent dans le cerveau humain; en tant que tels, ils ne peuvent pas être très complexes, et il est possible de construire un gros dictionnaire qui contiendra le mot de passe utilisateur avec une forte probabilité. Par "gros", je veux dire "peut être énuméré avec un cluster de taille moyenne en quelques semaines". Pour la discussion en cours, nous acceptons qu'un attaquant puisse casser un seul mot de passe en passant quelques semaines de calcul; c'est le niveau de sécurité que nous voulons atteindre.

Imaginez un attaquant passif: l'attaquant espionne mais ne modifie pas les messages. Il voit c et h (c || p) , donc il peut utiliser son cluster pour énumérer les mots de passe potentiels jusqu'à ce qu'une correspondance soit trouvée. Ce sera cher pour lui. Si l'attaquant veut attaquer deux mots de passe, alors il doit faire le travail deux fois . L'attaquant aimerait avoir un peu de partage des coûts entre les deux instances d'attaque, en utilisant des tables précalculées ("Les tables Rainbow" ne sont qu'une sorte de table précalculée avec un stockage optimisé; mais la construction d'une table Rainbow nécessite toujours d'énumérer le dictionnaire complet et de hacher chaque mot de passe). Cependant, le défi aléatoire bat l'attaquant: puisque chaque instance implique un nouveau défi, l'entrée de la fonction de hachage sera différente pour chaque session, même si le même mot de passe est utilisé. Ainsi, l'attaquant ne peut pas construire de tables précalculées utiles, notamment des tables Rainbow.

Supposons maintenant que l'attaquant devienne actif. Au lieu d'observer simplement les messages, il modifiera activement les messages, en supprimant certains, en dupliquant d'autres ou en insérant ses propres messages. L'attaquant peut désormais intercepter une tentative de connexion du client. L'attaquant choisit et envoie son propre défi ( c ') et attend la réponse du client ( h (c' || p) ). Notez que le vrai serveur n'est pas contacté; l'attaquant interrompt brusquement la connexion immédiatement après la réponse du client, afin de simuler une erreur réseau bénigne. Dans ce modèle d'attaque, l'attaquant a fait une grande amélioration: il a toujours un défi c ' et la réponse correspondante, mais le défi est une valeur qui l'attaquant a choisi comme bon lui semble. L'attaquant fera toujours le même défi c '. L'utilisation du même défi à chaque fois permet à l'attaquant d'effectuer des précalculs: il peut construire des tables précalculées (c'est-à-dire des tables Rainbow) qui utilisent ce "défi" spécial. Désormais, l'attaquant peut attaquer plusieurs mots de passe distincts sans encourir le coût d'énumération du dictionnaire pour chacun.

Un client nonce évite ce problème. Le protocole devient:

le serveur envoie un défi aléatoire c
le client choisit un nonce n (doit être distinct à chaque fois)
le client envoie n || h (c || n || p)
le serveur recalcule h (c || n || p) (en utilisant le p de sa base de données) et voit si cette valeur correspond à ce que le client a envoyé

Étant donné que le client inclut une nouvelle valeur aléatoire (le "nonce") dans l'entrée de fonction de hachage pour chaque session, l'entrée de fonction de hachage sera distincte à chaque fois, même si l'attaquant peut choisir le défi. Cela défait les tables précalculées (Rainbow) et restaure notre niveau de sécurité prévu.

Une émulation grossière d'un nonce unique est le nom d'utilisateur. Deux utilisateurs distincts au sein du même système auront des noms distincts. Cependant, l'utilisateur conservera son nom lorsqu'il modifiera son mot de passe; et deux utilisateurs distincts peuvent avoir le même nom sur deux systèmes distincts (par exemple, chaque système de type Unix a un utilisateur "root"). Le nom d'utilisateur n'est donc pas un bon nonce (mais c'est toujours mieux que de ne pas avoir de nonce client du tout).

Pour résumer, le nonce client consiste à protéger le client d'une attaque par rejeu (le "serveur" étant en fait un attaquant, qui enverra le même défi à chaque client qu'il souhaite attaquer). Cela n'est pas nécessaire si le défi est exécuté sur un canal qui inclut une authentification forte du serveur (comme SSL). Password Authenticated Key Exchange sont des protocoles avancés qui assurent une authentification mutuelle par mot de passe entre le client et le serveur, sans avoir besoin d'une confiance a priori (les "certificats racine" lorsqu'un client SSL authentifie le certificat du serveur SSL) et protégeant contre les attaquants actifs et passifs (y compris l'attaque "cluster-for-two-semaines" sur un seul mot de passe, donc c'est strictement mieux que le protocole ci-dessus, nonce ou no nonce).

Bosh · Answer

Permettez-moi d'essayer de répondre à la chair de votre question: "En supposant une seconde que l'attaquant ne souhaite pas s'engager dans une attaque par l'homme du milieu et souhaite récupérer les détails d'authentification, comment un cnonce fournit-il des informations supplémentaires protection?"

Généralement, un client non seulement inclut un nonce avec la demande, mais signe la demande entière, y compris le nonce. Cela signifie que même si l'attaquant intercepte un message entre le client et le serveur:

Une attaque de relecture ne fonctionnera pas (car le serveur garde une trace des nonces client).
L'attaquant ne peut pas simplement générer un nouveau message avec un nouveau client nonce, car il ne sait pas comment signer le nouveau message de manière appropriée (c.-à-d. il ne contient pas le secret client ou la clé privée).

paynes_bay · Answer

Selon RFC 2617 , les paramètres cnonce et nc protègent contre les attaques de texte en clair choisies. Comment cela protège-t-il contre de telles attaques?

Si Eve change le nonce que le serveur envoie au client, qu'est-ce qu'Eve a gagné? Eve ne peut pas générer h(password || nonce) à partir de h(password || fake_nonce) et en théorie, il semble que le serveur ne devrait pas accepter h(password || fake_nonce) de toute façon puisque le serveur doit savoir quel nonce est émis et quel nonce il n'a pas.

OJ. · Answer

Je pense qu'une bonne idée serait de lire comment la valeur nonce est utilisée dans quelque chose comme Oauth . En bref, lorsqu'une application utilisant OAuth fait une demande à un serveur pris en charge par OAuth, la demande doit contenir un tas de champs, dont deux sont horodatés et nonce. Le but du formulaire est évident: il donne une indication de la période pendant laquelle le message a été envoyé afin que le serveur puisse mieux deviner si le message est périmé. Ce dernier est évidemment un tas de caractères/octets aléatoires.

Lorsque l'intégralité de l'en-tête OAuth est hachée avec le secret du consommateur, ces deux champs sont inclus. Ensuite, la signature a a été ajoutée à la demande (qu'il s'agisse de paramètres de requête ou d'en-têtes HTTP) et envoyée sur au serveur. Le corps réel de la demande n'est pas haché.

Le serveur OAuth doit garder une trace de l'ensemble précédent de N valeurs nonce pour un client donné afin de s'assurer qu'elles ne sont pas réutilisées. Étant donné que le corps du message peut changer (essentiellement sans effet sur le hachage), il est important d'avoir quelque chose d'autre qui changera (c'est-à-dire le nonce) pour s'assurer que les demandes sont uniques. Compte tenu de la nature en texte ouvert/en clair de HTTP, c'est assez important.

Est-ce que cela aide à clarifier son objectif? (J'espère :)).