Algorithme pour la validation du code de message

Question

Si vous avez déjà lu ce fil de discussion - oubliez tout ce que j'ai écrit , je devais être saoul au moment de l'écrire. Je recommence:

Je travaille actuellement sur un projet dans lequel nous allons utiliser une sorte d'algorithme pour valider les entrées de l'utilisateur. Trois parties sont à prendre en compte;

Client: navigation sur nos pages Web

Société - Nous traitons les demandes du client

Société tierce - Gestion des messages client

Sur nos pages Web, nous montrerons au client des informations sur un produit. S'il souhaite obtenir plus d'informations sur le produit, il doit contacter la société tierce et lui indiquer le code du produit (non unique en soi, mais pas commun non plus). En retour, le client recevra un autre code de la société tierce qu'il devra saisir sur notre page Web, où nous validerons le code pour approbation.

Le mieux serait que nous, la société, n’entrions pas en interaction avec la société tierce. Le cryptage pur n’est pas visible car il génère une chaîne trop longue. Nous faisons cela par SMS, donc les codes doivent être courts.

Ce que j'ai proposé jusqu'à présent:

Pour chaque produit, je génère un code quelque peu unique (qu’il soit unique ou pas vraiment) en base 16 (0-f). Le client qui souhaite plus d'informations sur le produit envoie un SMS à la société tierce indiquant le code du produit. En retour, le client reçoit le même code, mais les chiffres sont multipliés (éventuellement par 2) et convertis en base 36. En plus de cela, un dernier caractère est ajouté au code, un numéro de contrôle, pour rendre le code valide pour le Luhn. algorithme en base 36. L’utilisateur entre le code reçu et nous, la Société, le validons côté serveur par rapport au code produit (validez contre Luhn, divisez par 2 et revenez en base 16).

Cela vous semble-t-il raisonnablement sûr et approprié? Est-ce un moyen valide d’envoyer des messages par trois parties, alors que deux d’entre elles ne devraient pas avoir besoin de communiquer?

Désolé pour la modification, mais mon esprit devait être ailleurs lorsque j'ai écrit le premier message.

Answer 1

Après de longs débats avec la société des 3 partis, nous avons conclu que la meilleure solution serait qu’ils me transmettent le SMS des clients. Je génère un nouveau code et le leur renvoie qui, à leur tour, envoie un nouveau SMS à le client avec le code que j'ai généré. Pas optimal de mon point de vue, mais au moins je peux maintenant le faire comme je le veux.

Merci pour votre contribution, tu.

Answer 2

Je pense que vous confondez les choses. Si vous utilisez l'algorithme de Luhn, par exemple, il ne fera que renvoyer Vrai ou Faux dans la somme de contrôle. L'exemple de code que vous avez donné semble indiquer que vous souhaitez obtenir un résultat de somme de contrôle (par exemple, 12345) pouvant être déchiqueté à partir de deux valeurs différentes. Ce problème serait plus difficile.

Comment le tiers créera-t-il cette valeur? Leur donnerez-vous du code Javascript à exécuter, ou un autre langage? Si vous ne pouviez pas avoir une clé secrète partagée et qu'ils puissent chiffrer la valeur de manière symétrique avec cette clé secrète, vous pourriez leur demander de préfixer la partie chiffrée avec une valeur connue afin de pouvoir la vérifier rapidement.

Leur code:

  to_send = encrypted(shared_key, 'check' + code)

Votre code:

  unencrypted = decrypt(shared_key, to_send)
  if not unencrypted.startswith('check'):
    return False # failed check

Answer 3

OK, vous ne souhaitez donc aucune interaction entre l’autre application et votre application. Et vous voudriez limiter les codes à 6 caractères. Voici mes pensées:

• Utilisez 10 caractères, ce qui rendra les attaques par force brute plus difficiles;
• Utilisez toutes les lettres latines et tous les chiffres - cela vous donnera 36 valeurs de caractères possibles;
• Pourquoi ne pas utiliser une bibliothèque de grands nombres et multiplier simplement votre code (pris comme un nombre Base36) par une valeur ridiculement grande (par exemple 2048 bits aléatoires). Puis convertissez-le en Base36 et prenez les 10 derniers chiffres. Ou peut-être les 5 premiers et les 5 derniers. Ou peut-être une autre combinaison dépendant du code d'origine. Je ne sais pas du tout à quel point cela sera fort cryptographiquement (probablement pas beaucoup), mais l'effort de déchiffrer le code sera sans doute moins important que de simplement payer pour le service.
• Vous pouvez également saler (ajouter une chaîne secrète) votre code, puis en calculer le MD5. Renvoyez le MD5 (ou quelques N caractères) à l'utilisateur sous forme de code. Cela devrait être assez cryptographiquement OK, bien que je ne sois pas un expert. En convertissant le résultat MD5 en Base36, vous pouvez augmenter la puissance de cet algorithme.

Answer 4

Pourquoi une "somme de contrôle"? La tierce partie ne peut-elle pas exécuter un petit utilitaire que vous lui donnez? Tout ce dont vous avez besoin est un crypteur à 5 chiffres que le tiers puisse exécuter sur son ordinateur, saisir le code du produit et envoyer le résultat à 5 chiffres au client sous forme de code de clé.

Le chiffreur produit toujours le même résultat à partir de la même entrée.

Ensuite, le client vous envoie le code produit et le code clé. Vous exécutez le code produit via une copie exacte de ce chiffreur et comparez ce résultat au code de la clé.

La sécurité de ce système peut être améliorée sans modifier l'architecture fondamentale.

-Al.

Answer 5

Modifier après quelques éclaircissements :

Je pense toujours que le code produit et la réponse tierce correspondante ne peuvent pas être constants - sinon, il peut être partagé par d'autres utilisateurs, qui pourront ainsi donner le code de réponse sans passer par la tierce partie.

Si le code produit est constant, une solution possible est que la réponse du tiers dépende du texte et du numéro de téléphone de l'utilisateur. Il en va de même de votre validation. Ainsi, chaque réponse est à la fois spécifique au produit et à l'utilisateur.

La permutation spécifique de l'algorithme de Luhn n'est pas très importante à mon avis - si quelqu'un peut déchiffrer une variation, il pourra probablement en craquer une autre.

Réponse originale :

En bref, je pense que vous pouvez utiliser l'algorithme de Luhn, si vous donnez à l'utilisateur un ticket unique, valable pour une durée limitée.

• Tout d'abord, si je comprends bien le problème, votre code produit ne peut pas être constant. Sinon, la réponse créée par la tierce partie sera toujours la même pour ce produit. Cela signifie que l'utilisateur pourra utiliser ce code ultérieurement, ou même le donner à un autre utilisateur.
• Par conséquent, je pense que vous devriez générer et donner à l'utilisateur un nouveau code aléatoire par demande d'information / d'accès au produit. Ce code doit être valable pour ce produit pendant une période limitée (une heure, une journée, en fonction de vos besoins).
• La réponse envoyée par la tierce partie à l'utilisateur ne doit être valide que si elle est entrée avec le code que vous avez fourni à l'utilisateur.
• Après validation, ce code ne peut être utilisé avant la fin du délai spécifié.
• En option, je pense que vous et le tiers pouvez ajouter quelque chose comme la date du jour au code et à la réponse lors du calcul, afin qu'ils ne soient pas toujours identiques.