Sécurité, cryptographie: Stupid Challenge - Response protocol?

Question

Ok les gars, juste un petit jeu:

J'ai des spécifications pour un projet. À un moment donné, ils demandent ce qui suit pour chiffrer un mot de passe sur le réseau, en disant qu'il s'agit d'un protocole de réponse à une épreuve:

CLIENT ----------------------------- SERVER

(1)ask for challenge -------------->

(2)    <---------------------------- send SHA1 taken from the time
                                       (this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password

(4)    <---------------------------- Grant access

Pour ceux qui ne le savent pas, SHA signifie Secure Hashing Algorithm, un algorithme standard pour la cryptographie.

J'espère que c'est clair. La question est: Si je renifle les paquets 2 et 3 (le "défi" et le "défi du mot de passe xor", j'ai le mot de passe réel avec juste un autre xor entre les deux!?!? Il existe un autre moyen de mettre en œuvre ce type du protocole ??

Answer 1

Que diriez-vous de ce qui suit:

1. Le serveur envoie un défi aléatoire
2. Le client envoie la somme de contrôle SHA1 de (défi + mot de passe)
3. Les serveurs comparent la somme de contrôle SHA1 de (défi + mot de passe stocké)

Answer 2

Vous pourrez procéder au reverse engineering du mot de passe. Vous voulez envoyer le SHA du mot de passe, pas le mot de passe lui-même. Faire rouler ses propres protocoles de sécurité n'est presque jamais une bonne idée. Ne pouvez-vous pas utiliser SSL ou quelque chose d’équivalent?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Answer 3

C'est un protocole assez horrible. Si c'est quelque chose que quelqu'un veut que vous implémentiez, refusez. Il existe des protocoles validés pour ce type de choses. S'il s'agit d'un jeu dans lequel vous signalez toutes les failles, d'accord.

• Toute personne entendant les étapes 2 & amp; 3 connaît le mot de passe
• Toute personne entendant l'étape 3 et notant l'heure peut forcer brute le mot de passe s'il a une idée de la précision de l'heure sur le serveur
• Je peux prétendre être un serveur (intoxication par un arp, rediction de DNS, etc.) et obtenir votre mot de passe, ne jamais effectuer l'étape 4 et feindre un dépassement de délai
• Vulnérable à Man in the Middle Attacks car il n'y a pas de secret partagé entre client / serveur ou de certificats sur le serveur
• S'appuie sur le serveur qui stocke SHA1 (heure) et attend une réponse. Je peux donc surcharger le serveur avec des demandes de contestation sans jamais répondre.

Et il me manque définitivement un peu plus.

Answer 4

Vous avez raison - si vous capturez le défi et (mot de passe challenge XOR), alors extraire le mot de passe est facile.

Vous devez utiliser le chiffrement approprié à l'étape 3, pas XOR. Cryptez le défi avec le mot de passe.

Pour rendre la vie d'un attaquant plus difficile, vous pouvez ajouter des données aléatoires à ce que vous chiffrez: par exemple. chiffrer paddingCHALLENGEpadding. Le serveur ne s’intéresse pas à la nature du remplissage, il sait où chercher le défi, mais un attaquant ne saura pas quel est le texte intégral.

Answer 5

Comme l’ont souligné les autres, vous avez raison. N'oubliez pas non plus que quelqu'un peut intercepter la communication (3) et éventuellement la renvoyer alors que l'utilisateur réel est confronté à des problèmes de réseau (par exemple: un DDOS), l'imposteur serait alors connecté et qu'il suffirait souvent de changer le mot de passe (c'est-à-dire , de nombreux systèmes n'exigent pas que vous fournissiez un mot de passe pour le changer une fois que vous êtes connecté).

Vous pouvez envisager HMAC (code d'authentification de message avec hachage à clé). J'ai blogué à ce sujet en détail ici: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html et un bref résumé ci-dessous.

HMAC est une méthode permettant de s'assurer qu'un message a été généré par une personne ayant accès à un secret partagé. HMAC utilise une sorte de fonction de hachage à sens unique (comme MD5 ou SHA-1) pour chiffrer le secret avec un message. Cela génère un résumé de 16 à 20 octets qui agit comme une empreinte de la combinaison message + secret. Lorsque le résumé est envoyé avec le message, le destinataire (notre serveur) peut régénérer le hachage avec le même calcul HMAC et comparer le résumé généré localement avec le résumé fourni avec le message. Rappelez-vous: le serveur a aussi le secret, il a donc assez d’informations pour confirmer le résumé. (Cela ne concerne que le problème de la vérification de l'origine d'un message, mais vous pouvez utiliser la même approche pour chiffrer l'intégralité du message, si vous utilisez un secret différent, par exemple un ensemble de clés publiques.)

Answer 6

Voici comment je procéderais:

1. Mettez le serveur à l’épreuve.

2. Le serveur répond avec sa clé publique (pour, dire le cryptage RSA) numériquement signé.

3. Le client vérifie la PC et crypte mot de passe avec la clé, puis signe numériquement le chiffré mot de passe.

4. Le serveur vérifie la signature et déchiffre le mot de passe pour le stocker / le vérifier.

La signature numérique est importante dans la mesure où elle constitue le début de la prévention des attaques de type "homme au milieu".

Answer 7

Comme d’autres l’ont déjà fait remarquer, c’est un algorithme de réponse à une question difficile.

Vous voudrez probablement consulter Authentification Digest , utilisée par HTTP. En fait, si votre protocole est via HTTP, vous pouvez ignorer l’écriture de votre choix et simplement l’utiliser ou l’implémenter.

Answer 8

chiffrement à clé publique? Utilisez la clé publique du serveur pour chiffrer le mot de passe.

Answer 9

Bien que le déploiement de votre propre protocole cryptographique ne soit jamais une bonne solution, je ne le recommanderais pas ....

Pour surmonter le problème auquel vous êtes confronté ... F - Une fonction qui prend le mot de passe et une valeur pseudo-aléatoire augmentant de façon monotone et renvoie un nombre. Par exemple Hash (Hash (Mot de passe) ^ Horodatage)

1. Serveur: demander un défi, envoyer (horodatage). Mémoriser le dernier horodatage envoyé.
2. Client, Envoyer la réponse (Envoyer F (Mot de passe, Horodatage) et Horodatage)
3. Serveur: vérifiez le client à l'aide du hachage (mot de passe) et de l'horodatage envoyés par le client (> Horodatage envoyé dans le Challenge).
4. Si le client est correct, accordez l'accès.
5. Assurez-vous que l'horodatage actuel est supérieur à tous les horodatages envoyés par le client avant le prochain défi pour empêcher les attaques par relecture.

Cordialement, Ashish Sharma

Answer 10

Je crois que Diffie-hellman est un protocole d’échange de clés bien connu et solide?