Des idées pour créer un petit (<10 chiffres), pas (très) sécurisé « hachage »

Question

Je travaille sur un système de billetterie événement en ligne, où les utilisateurs seront en mesure d'auto imprimer ses billets et montrer à l'événement où il sera numérisé (code à barres) et idéalement la personne entrer. Mon problème est de savoir comment pour créer un « code de ticket » qui remplit les conditions suivantes:

• chaque « code de ticket » doivent être suffisamment différents les uns des autres (non numérotés de manière séquentielle)
• Idéalement, le billet sera vérifié par rapport à un DB central pour empêcher la réutilisation, mais il doit être en mesure de travailler hors ligne aussi, dans ce cas, le système doit vérifier un code de ticket « valide » et qu'il n'a pas été utilisé dans cette porte.
• le « code de ticket » doit être assez petit pour faciliter la saisie si nécessaire
• le détenteur du billet aurait seulement besoin du ticket pour entrer (pas de contrôle d'identité)

La gamme des données est très faible, il n'y aura que 20 événements de plus de 4 jours avec environ 5.000 billets par événement (environ 100 000 codes de billets différents)

Maintenant, j'ai plusieurs champs qui ne sont pas imprimés sur le billet et non connu à l'utilisateur que je peux utiliser pour coder une partie du « code de ticket », pour que je puisse utiliser le EventId, OrderId, EventDate et un peu de sel pour créer un petit « hachage » pour une partie du code (des idées?), mais je suis toujours bloqué avec le numéro de dossier qui est séquentiel ou un GUID (serait trop long)

des idées ou conseils sur la façon de le faire?

Answer 1

Soit un schéma très simple basé sur un réseau de Feistel permutant, par exemple, le numéro d'identification de billets. Ce message (qui se trouve être sur les listes de PostgreSQL, mais n'a pas vraiment grand-chose à voir avec PostgreSQL) décrit simple réseau Feistel . Sur chaque billet, vous pouvez imprimer un numéro d'identification de billets (choisi séquentiellement), puis un « code secret ticket » qui est le résultat de mettre le numéro d'identification à travers un réseau de Feistel. Les variations possibles incluent l'ajout d'un chiffre de contrôle du code secret, et en fondant l'entrée du réseau Feistel sur plus que le nombre généré de manière séquentielle (nombre + 10 000 * numéro d'événement, et ainsi de suite).

Answer 2

Pourquoi réinventer la roue? Il suffit de faire quelque chose comme ça (Python code, demandez-moi si vous avez besoin d'éclaircissements):

import hashlib

secretpassword = "blah"

def createticket(eventnum, ticketnum):
    m = hashlib.md5() # or any crypto hash you like
    m.update("%s%s%s" % (eventnum, ticketnum, secretpassword))
    return m.hexdigest()[:10]

Exemple:

Numéro d'événement 1

Ticket Number 123

createticket(1,123)
# output: 2d7f242597

M. ticketman vient autour de son vérificateur et entre dans l'événement / numéro de ticket et le hachage:

def verifier(eventnum, ticketnum, hash):
    return hash == createticket(eventnum, ticketnum)

verifier(1,123, "2d7f242597")
# ouput: True

Answer 3

Je vous suggère de donner algorithme Verhoeff essayer.

Answer 4

Deux façons je peux voir:

1. générer un nombre aléatoire, ou au moins une partie aléatoire pour un certain nombre, et le stocker dans une base de données centrale. Ensuite, téléchargez la base de données dans tous les systèmes de porte pour vérifier contre.
2. Le nombre doit être autonome. En d'autres termes, le nombre doit être en mesure de vérifier sans la liste enregistrée. Cela ressemble à une sorte de système de contrôle. Par exemple, vous pouvez émettre des numéros de 1 et vers le haut, faites-les 5 chiffres (00000-99999 = 100.000 numéros), et prepende 1-3 lettres, en vous assurant de se retrouver avec une somme de contrôle qui vérifier.

Answer 5

Pour la vérification en ligne, je ne vois qu'une seule solution facile ..

Append à l'ID de billet un hachage de l'ID de billets et un sel par événement. Vous pouvez tronquer tout hachage cryptographique à la taille désirée. Je ne peux pas penser à une raison particulière d'utiliser quoi que ce soit, mais un nombre aléatoire pour l'ID de billet de base lui-même.

Cela vous permet de limiter la taille de l'ID de billets et une sécurité clairement proportionnelle par rapport à la taille de l'ID de billet.

Answer 6

Vous pouvez faire un calcul CRC.

En fait, il suffit de commencer à ajouter chaque caractère de la chaîne, et de limiter la longueur à un entier long.

Vous pouvez commencer par un nombre aléatoire connu et le stocker dans les 4 premiers octets, et ont les quatre derniers un calcul comme je l'ai décrit plus haut.

Ce serait deux ints ou huit octets.

Answer 7

Voici un schéma qui a l'avantage de laisser calculer le hachage suivant ticket de la précédente (vous pouvez donc vérifier si un manque), mais ne laisse pas les étrangers calculer la suivante:

Ticket.0 = substring(HASH(SALT + IV        ), 0, LENGTH)
Ticket.i = substring(HASH(SALT + Ticket.i-1), 0, LENGTH)

où

• HASH est une fonction de hachage qui distribue son entropie relativement uniformément sur toute la chaîne de sortie
• SALT est une constante vous garder un secret; c'est une bonne idée d'utiliser un différent pour chaque événement
• IV est une autre constante vous garder un secret
• longueur est la longueur de l'ID de billet que vous voulez (10 dans votre question, mais 12 n'est pas hors de question et vous donne 256 fois plus ID de ticket)