Ideas para crear un pequeño (<10 dígitos), no (muy) seguro “de marca”

Question

Estoy trabajando en un evento en línea del sistema, donde los usuarios serán capaces de auto imprimir sus billetes y se muestran en el evento donde se escaneará (código de barras) y lo ideal es que la persona se pondrá en venta de entradas. Mi problema es cómo para crear un "código de billete" que cumpla con los siguientes requisitos:

• cada "código de billete" necesita ser suficientemente diferentes entre sí (es decir, no numeradas secuencialmente)
• idealmente el billete se cotejará con una base de datos central para evitar la reutilización, pero tiene que ser capaz de trabajar fuera de línea también, en cuyo caso el sistema tiene que comprobar si hay un código de billete "válida" y que no ha sido utilizado en este puerta.
• el "código de billete" tiene que ser lo suficientemente pequeño como para facilitar keying si es necesario
• el titular del billete necesitaría solamente el boleto para entrar (es decir, sin verificación de ID)

El rango de los datos es muy pequeño, sólo habrá unos 20 eventos durante 4 días con alrededor de 5.000 entradas por evento (cerca de 100.000 entradas códigos diferentes)

Ahora tengo varios campos que no están impresos en el billete y no se sabe que el usuario que puede utilizar para codificar parte del "código de billete", por lo que podría utilizar el EventId, OrderId, EVENTDATE y un poco de sal para crear un pequeño "control" de parte del código (ideas?), pero todavía tengo que quedar con el identificador de boleto que es secuencial o un GUID (sería demasiado largo)

Así que cualquier ideas o consejos sobre cómo hacer esto?

Answer 1

Considere un esquema muy simple basado en una red de Feistel para permutar, por ejemplo, el número de identificación billete. Este mensaje (que pasa a ser en las listas, pero PostgreSQL realmente no tiene mucho que ver con PostgreSQL) describe un Feistel red . En cada billete se podía imprimir un número de identificación de billetes (elegido de forma secuencial), entonces un "código secreto billete" que es el resultado de poner el número de identificación a través de una red de Feistel. Las posibles variaciones incluyen añadiendo un dígito de control para el código secreto, y basando la entrada a la red de Feistel en algo más que el número secuencial generado (número + 10 000 * Número de ID de evento, etcétera).

Answer 2

¿Por qué reinventar la rueda? Sólo hacer algo como esto (Código Python, me pregunta si necesita aclaración):

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]

Ejemplo:

Número de evento 1

Número de billete 123

createticket(1,123)
# output: 2d7f242597

Mr ticketman, vuelve con su verificador y entra en el número de evento / billete y el hash:

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

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

Answer 3

Le sugiero que da la algoritmo de Verhoeff intentarlo.

Answer 4

Dos maneras en que puedo ver:

1. Generar un número aleatorio, o al menos una parte aleatoria de un número, y almacenarla en una base de datos central. A continuación, descargar la base de datos en todos los sistemas de puertas para comprobar en contra.
2. El número tiene que ser autosuficiente. En otras palabras, el número tiene que ser capaz de ver sin la lista guardada. Esto suena como una especie de sistema de suma de comprobación. Por ejemplo, puede emitir números del 1 y hacia arriba, hacerlos 5 dígitos (00000-99999 = 100.000 números), y prepende 1-3 letras, asegurándose de que usted termina con una suma de comprobación que se echa un vistazo.

Answer 5

Para la verificación fuera de línea, sólo veo una solución fácil ..

Añadir a la ID del ticket un hash de la identificación del billete y una sal por evento. Puede limitar cualquier hash criptográfica al tamaño deseado. No puedo pensar en una razón en particular para usar nada más que un número aleatorio para el mismo ID de ticket de base.

Esto le permite limitar el tamaño de la ID del ticket y tienen un valor claramente proporcional en relación con el tamaño de la ID del ticket.

Answer 6

Se puede hacer un cálculo CRC.

Básicamente, acaba de empezar a agregar cada carácter de la cadena, y limitar la longitud a un entero largo.

Usted puede comenzar con un número aleatorio conocido y lo almacenan en los primeros 4 bytes, y tienen los últimos cuatro haber un cálculo que he descrito anteriormente.

Esto sería dos enteros, u ocho bytes.

Answer 7

Aquí hay un esquema que tiene la ventaja de permitir que se calcula el hash de la próxima billete de la anterior (para que pueda verificar si falta uno), pero no permite que los extranjeros calculan el siguiente:

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

donde

• HASH es cualquier función hash que distribuye su entropía relativamente uniformemente a través de la cadena de salida
• SALT es una constante a mantener en secreto; que es una buena idea utilizar uno diferente para cada evento
• IV es otra constante se mantiene en secreto
• longitud es la longitud del identificador de boleto que desea (10 en su pregunta, pero 12 no está fuera de la cuestión y le da 256 veces más que los ID de entradas)