Ideen zu einer kleinen (<10 Ziffern) zu erstellen, nicht (sehr) sichern „hash“

StackOverflow https://stackoverflow.com/questions/890907

Frage

Ich bin auf einer Online-Event-Arbeits Ticketing-System, in dem Benutzer in der Lage sein wird, mich selbst seine Karten drucken und auf der Veranstaltung zeigen, wo es (Barcode) und im Idealfall der Person gescannt werden wird erhalten. Mein Problem ist, wie ein „Ticket-Code“ zu erstellen, die die folgenden Voraussetzungen erfüllt:

  • jeder „Ticket-Code“ muß ausreichend voneinander verschieden sein (dh nicht fortlaufend nummeriert)
  • idealerweise wird das Ticket gegen einen zentralen DB überprüft werden, die Wiederverwendung zu verhindern, aber es muss in der Lage sein zu arbeiten off line, wobei in diesem Fall des System für einen „gültigen“ Ticket-Code zu überprüfen hat, und dass es nicht gewesen verwendet in das Tor.
  • der „Ticket-Code“ hat klein genug sein, zu erleichtern es Keying bei Bedarf
  • die Ticketinhaber würden nur noch das Ticket zu bekommen (dh keinen ID-Check)

Der Bereich der Daten ist sehr klein, es wird nur etwa 20 Veranstaltungen über 4 Tage mit über 5.000 Tickets pro Veranstaltung (ca. 100.000 verschiedener Ticket-Codes)

sein

Jetzt habe ich mehrere Felder, die auf dem Ticket nicht gedruckt werden und den Benutzer nicht bekannt, dass ich verwenden kann, einen Teil des „Ticket-Code“ codieren, so konnte ich die EventId, OrderId, eventdate und etwas Salz zum Erstellen ein kleines „hash“ für einen Teil des Codes (Ideen?), aber ich bin immer noch mit der Ticket-ID fest, der sequentiellen oder einer GUID (wäre zu lang)

ist

So irgendwelche Ideen oder Hinweise, wie dies zu tun?

War es hilfreich?

Lösung

Betrachten wir ein sehr einfaches Schema basiert auf einem Feistel-Netzwerk permutieren, sagen wir, die Ticket-ID-Nummer. Diese Meldung (die auf den PostgreSQL-Listen werden passiert, aber nicht wirklich viel mit PostgreSQL zu tun) beschreibt eine einfache Feistel Netzwerk . Auf jedem Ticket eine Ticket-ID-Nummer (sequentiell gewählt) drucken konnte, dann ein „Ticket Geheimcode“, das ist das Ergebnis der Umsetzung der ID-Nummer durch ein Feistel-Netzwerk. Mögliche Varianten enthalten eine Prüfziffer, um den geheimen Code angehängt, und die Eingabe in das Netzwerk Feistel basiert auf mehr als nur die sequentiell generierte Nummer (Nummer + 10.000 * Ereignis-ID-Nummer, etc.).

Andere Tipps

Warum das Rad neu erfinden? Tun Sie einfach so etwas wie dieses (Python-Code, fragen Sie mich, wenn Sie Klärung bedürfen): 

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]

Beispiel:

Ereignis Nummer 1

Ticketnummer 123 

createticket(1,123)
# output: 2d7f242597

Herr Ticketman kommt um mit seinem Prüfer und tritt im Falle / Ticketnummer und der Hash-: 

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

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

Ich schlage vor, Sie die Verhoeff Algorithmus einen Versuch.

Zwei Arten kann ich sehen:

  1. Erzeugen einer Zufallszahl, oder zumindest einen zufälligen Teil für eine Nummer, und speichern sie in einer zentralen Datenbank. Dann laden Sie die Datenbank in alle Toranlagen gegen überprüfen.
  2. Die Nummer muss autark sein. Mit anderen Worten hat sich die Zahl der Lage sein, ohne dass die gespeicherte Liste zu überprüfen. Das klingt wie eine Art Prüfsumme Systems. Zum Beispiel könnten Sie die Zahlen von 1 ausgeben und nach oben, so dass ihnen 5-stellig machen (00.000-99.999 = 100.000 Zahlen) und prepende 1-3 Buchstaben, dafür, dass Sie mit einer Prüfsumme am Ende, das würde überprüfen.

Für die Offline-Überprüfung, ich sehe nur eine einfache Lösung ..

Fügen Sie an dem Ticket-ID einen Hash-Wert der Ticket-ID und ein Pro-Ereignis Salz. Sie können eine beliebige kryptographische Hash auf die gewünschte Größe gestutzt. Ich kann nicht aus einem bestimmten Grund denken, alles andere als eine Zufallszahl für die Basis-Ticket-ID selbst zu verwenden.

Auf diese Weise können Sie die Größe der Ticket-ID und haben eine deutlich proportional Sicherheit in Bezug auf die Größe der Ticket-ID begrenzen.

Sie könnten eine CRC-Berechnung tun.

Im Grunde beginnt nur jedes Zeichen in der Zeichenfolge hinzuzufügen, und die Länge auf eine lange ganze Zahl zu begrenzen.

Sie können mit einer bekannten Zufallszahl und speichern sie in dem ersten 4 Bytes starten, und haben die letzten vier eine Berechnung sein, wie ich oben beschrieben.

Dies würde zwei ints oder acht Bytes sein.

Hier ist ein Schema, das den Vorteil, dass hat man den nächsten Ticket-Hash aus dem vorherige Berechnung (so können Sie überprüfen, ob eine fehlt), aber sie nicht Außenseiter die nächsten berechnen: 

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

Dabei steht

  • HASH ist jede Hashing-Funktion, die seine Entropie relativ gleichmäßig über die Ausgabezeichenfolge
    • vertreibt
  • SALT ist eine Konstante, die Sie geheim zu halten; es ist eine gute Idee, ein anderes für jedes Ereignis
    • zu verwenden
  • IV ist eine weitere Konstante, die Sie geheim halten
  • LÄNGE ist die Länge der Ticket-ID Sie wollen (10 in Frage, aber 12 ist nicht die Frage aus und gibt Ihnen 256-mal so viele Ticket-IDs)
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top