16

私は、ユーザーが自分のチケットを自分で印刷し、スキャン (バーコード) され、理想的にはその人が入場するイベントに参加できるオンライン イベント チケット システムに取り組んでいます。私の問題は、以下の条件を満たす「チケットコード」

  • 各「チケットコード」は互いに十分に異なっている必要があります (つまり、連続番号が付けられていません)。
  • 理想的には、チケットは再利用を防ぐために中央データベースに対してチェックされますが、オフラインでも作業できるようにする必要があります。ゲート。
  • 「チケットコード」は、必要に応じて簡単に入力できるように十分に小さくする必要があります
  • チケット所有者は、入場するためにチケットのみを必要とします (つまり、ID チェックは必要ありません)。

データの範囲は非常に小さく、イベントごとに約 5,000 チケット (約 100,000 の異なるチケット コード) で、4 日間にわたって約 20 のイベントしかありません。

現在、チケットに印刷されておらず、「チケットコード」の一部をエンコードするために使用できるユーザーには知られていないフィールドがいくつかあるため、EventId、OrderId、EventDate、およびいくつかのソルトを使用して小さな「コードの一部（アイデア？）のハッシュ」ですが、まだシーケンシャルまたはGUIDのチケットIDにこだわっています（長すぎるでしょう）

これを行う方法についてのアイデアや指針はありますか？

4

7 に答える 7

13

なぜ車輪を再発明するのですか？次のようなことをしてください（Pythonコード、説明が必要かどうか尋ねてください）：

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]

例：

イベント番号 1

チケット番号123

createticket(1,123)
# output: 2d7f242597

チケットマン氏はベリファイアを持ってやって来て、イベント/チケット番号とハッシュを入力します。

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

verifier(1,123, "2d7f242597")
# ouput: True
于 2009-05-21T03:16:10.390 に答える
5

Verhoeff アルゴリズムを試してみることをお勧めします。

于 2009-05-21T00:35:35.177 に答える
3

私が見ることができる2つの方法：

  1. 乱数、または少なくとも乱数の一部を生成し、中央データベースに保存します。次に、チェックするすべてのゲート システムにデータベースをダウンロードします。
  2. 数は自給自足でなければなりません。つまり、番号は保存されたリストなしでチェックアウトできる必要があります。これは、ある種のチェックサム システムのように思えます。たとえば、1 以上の数字を発行し、それらを 5 桁 (00000-99999 = 100.000 の数字) にし、1 ～ 3 文字を先頭に追加して、最終的にチェックアウトされるチェックサムになるようにすることができます。
于 2009-05-21T00:37:16.547 に答える
1

Feistel ネットワークに基づいて、たとえばチケット ID 番号を並べ替える非常に単純なスキームを考えてみましょう。このメッセージ(たまたま PostgreSQL のリストに載っていますが、実際には PostgreSQL とはあまり関係がありません) は、単純なFeistel ネットワークについて説明しています。各チケットには、チケット ID 番号 (順番に選択) を印刷し、次に ID 番号を Feistel ネットワークに通した結果である「チケット シークレット コード」を印刷できます。可能性のあるバリエーションには、秘密コードにチェック ディジットを追加することや、Feistel ネットワークへの入力を、連続して生成された番号 (番号 + 10,000 * イベント ID 番号など) 以上に基づいて行うことが含まれます。

于 2009-05-21T01:27:49.657 に答える
0

CRC計算を行うことができます。

基本的には、文字列の各文字の追加を開始し、長さを長整数に制限します。

既知の乱数から始めて、最初の4バイトに格納し、最後の4つを前述のように計算することができます。

これは2int、つまり8バイトになります。

于 2009-05-21T02:19:41.953 に答える
0

これは、前のチケット ハッシュから次のチケット ハッシュを計算できるという利点がある (そのため、欠落しているかどうかを確認できる) が、部外者が次のチケットを計算できないようにするスキームです。

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

どこ

  • HASHエントロピーを出力文字列全体に比較的均等に分散する任意のハッシュ関数です
  • SALT秘密にしておく定数です。イベントごとに異なるものを使用することをお勧めします
  • IVあなたが秘密にしているもう一つの定数です
  • LENGTH は、必要なチケット ID の長さです (質問では 10 ですが、12 は問題外ではなく、256 倍のチケット ID が得られます)。
于 2009-05-21T02:48:21.087 に答える
0

オフライン検証については、簡単な解決策が 1 つしかありません。

チケット ID に、チケット ID のハッシュとイベントごとのソルトを追加します。任意の暗号化ハッシュを必要なサイズに切り詰めることができます。ベース チケット ID 自体に乱数以外を使用する特定の理由は考えられません。

これにより、チケット ID のサイズを制限し、チケット ID のサイズに対して明らかに比例したセキュリティを持つことができます。

于 2009-05-21T01:14:40.247 に答える