Ideas to create a small (<10 digits), not (very) secure "hash"

Question

I'm working on an online event ticketing system, where users will be able to self print his tickets and show up at the event where it will be scanned (barcode) and ideally the person will get in. My problem is how to create a "ticket code" that fulfills the following requirements:

• each "ticket code" need to be sufficiently different from each other (ie not sequentially numbered)
• ideally the ticket will be checked against a central DB to prevent reuse, but it NEEDS to be able to work off line too, in which case the system has to check for a "valid" ticket code and that it has not been used in this gate.
• the "ticket code" has to be small enough to facilitate keying it if needed
• the ticket holder would only need the ticket to get in (ie no ID check)

The range of the data is very small, there will only be about 20 events over 4 days with about 5,000 tickets per event (about 100,000 different ticket codes)

Now I have several fields that are not printed on the ticket and not known to the user that I can use to encode part of the "ticket code", so I could use the EventId, OrderId, EventDate and some salt to create a small "hash" for part of the code (ideas?), but I'm still stuck with the ticket id that is sequential or a GUID (would be too long)

So any ideas or pointers on how to do this?

Answer 1

Why reinvent the wheel? Just do something like this (Python Code, ask me if you need clarification):

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]

Example:

Event Number 1

Ticket Number 123

createticket(1,123)
# output: 2d7f242597

Mr ticketman comes around with his verifier and enters in the event/ticket number and the hash:

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

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

Answer 2

I suggest you give the Verhoeff algorithm a try.

Answer 3

Two ways I can see:

1. Generate a random number, or at least a random part for a number, and store it in a central database. Then download the database into all the gate systems to check against.
2. The number has to be self-sufficient. In other words, the number has to be able to check out without the saved list. This sounds like some kind of checksum system. For instance, you could issue numbers from 1 and upwards, make them 5 digits (00000-99999 = 100.000 numbers), and prepende 1-3 letters, making sure you end up with a checksum that would check out.

Answer 4

Consider a very simple scheme based on a Feistel network to permute, say, the ticket ID number. This message (which happens to be on the PostgreSQL lists but doesn't really have much to do with PostgreSQL) describes a simple Feistel network. On each ticket you could print a ticket ID number (sequentially chosen), then a "ticket secret code" that's the result of putting the ID number through a Feistel network. Possible variations include appending a check digit to the secret code, and basing the input to the Feistel network on more than just the sequentially generated number (number + 10,000 * event ID number, et cetera).