Ideias para criar um pequeno (<10 dígitos), não (muito) seguro “haxixe”

Question

Eu estou trabalhando em um evento on-line do sistema, onde os usuários serão capazes de auto imprimir seus bilhetes e mostrar-se no evento onde será digitalizada (código de barras) e, idealmente, a pessoa bilhética vai entrar. O meu problema é como para criar um "código de bilhete" que cumpre os seguintes requisitos:

• cada necessidade "código de bilhete" que seja suficientemente diferente um do outro (ou seja, não numerado sequencialmente)
• idealmente o bilhete será verificada contra um DB central para evitar a reutilização, mas ele precisa ser capaz de trabalhar fora de linha também, caso em que o sistema tem de verificar se há um código de bilhete "válido" e que não foi usado em este portão.
• o "código bilhete" tem de ser pequeno o suficiente para facilitar digitando-se necessário
• o portador do bilhete só precisa o bilhete para entrar (ou seja, sem verificação de ID)

A gama dos dados é muito pequeno, haverá apenas cerca de 20 eventos ao longo de 4 dias, com cerca de 5.000 ingressos por evento (cerca de 100.000 diferentes códigos de ingressos)

Agora tenho vários campos que não são impressas no bilhete e não se sabe se o usuário que eu possa usar a parte de codificação do "código do bilhete", para que eu pudesse usar o EventId, OrderId, EVENTDATE e um pouco de sal para criar um pequeno "Hash" para parte do código (idéias?), mas eu ainda estou preso com o ID de bilhete que é seqüencial ou um GUID (seria demasiado longo)

Assim, quaisquer ideias ou sugestões sobre como fazer isso?

Answer 1

Considere um esquema muito simples baseado em uma rede de Feistel permutar, por exemplo, o número de identificação do bilhete. Este mensagem (que passa a ser nas listas do PostgreSQL, mas realmente não tem muito a ver com PostgreSQL) descreve um simples Feistel rede. Em cada bilhete que você pode imprimir um número de identificação do bilhete (sequencialmente escolhido), em seguida, um "código secreto bilhete" que é o resultado de colocar o número de identificação através de uma rede Feistel. variações possíveis incluem acrescentar um dígito de verificação para o código secreto, e baseando a entrada para a rede Feistel em mais do que apenas o número gerado sequencialmente (número + 10.000 * Número de identificação de evento, et cetera).

Answer 2

Por que reinventar a roda? Basta fazer algo como isto (código Python, me pergunte se você precisar de esclarecimentos):

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]

Exemplo:

Número Evento 1

Ticket Número 123

createticket(1,123)
# output: 2d7f242597

Mr ticketman vem por aí com seu verificador e entra no número de eventos / ingressos e o hash:

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

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

Answer 3

Eu sugiro que você dê o Verhoeff algoritmo uma tentativa.

Answer 4

Duas maneiras que eu posso ver:

1. Gerar um número aleatório, ou pelo menos uma parte aleatória para um número, e armazená-lo em um banco de dados central. Então baixe o banco de dados em todos os sistemas de porta para verificar contra.
2. O número tem de ser auto-suficiente. Em outras palavras, o número tem de ser capaz de verificar sem a lista salva. Isso soa como algum tipo de sistema de verificação. Por exemplo, você poderia emitir números de 1 e para cima, torná-los 5 dígitos (00000-99999 = 100.000 números), e prepende 1-3 cartas, certificando-se de que você acabar com uma soma de verificação que gostaria check-out.

Answer 5

Para a verificação off-line, eu vejo apenas uma solução fácil ..

Anexar ao ID do ticket um hash da ID do ticket e um sal de per-evento. Pode cortar qualquer hash criptográfico para o tamanho desejado. Eu não posso pensar em uma razão especial para usar qualquer coisa, mas um número aleatório para o próprio ID bilhete de base.

Isso permite que você limitar o tamanho do ID bilhete e ter uma segurança claramente proporcional em relação ao tamanho do ID do ticket.

Answer 6

Você poderia fazer um cálculo CRC.

Basicamente, basta começar a adicionar cada caractere na seqüência, e limitar o comprimento de um inteiro longo.

Você pode começar com um número aleatório conhecido e armazená-lo nos primeiros 4 bytes, e ter a última de quatro ser um cálculo como eu descrevi anteriormente.

Este seria dois ints, ou oito bytes.

Answer 7

Aqui está um esquema que tem a vantagem de permitir que você calcular o próximo hash de bilhete do anterior (para que você possa verificar se um está faltando), mas não deixa de fora calcular a próxima:

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

onde

• HASH é qualquer função hash que distribui a sua entropia relativamente uniformemente em toda a cadeia de saída
• SALT é uma constante que você manter em segredo; é uma boa idéia usar um diferente para cada evento
• IV é outra constante que você manter em segredo
• comprimento é o comprimento da ID do ticket que você quer (10 em sua pergunta, mas 12 não está fora de questão e dá-lhe 256 vezes mais IDs de ingressos)