cryptography - 重複するクレジットカード番号を保存せずに特定するための最良の方法は何ですか？

Question

私は、特定のアカウントを詐欺師としてマークし、そのアカウントと使用されたすべてのクレジットカードに不正として「フラグを立てる」Webサイトを運営しています。実際のクレジットカードの値は保存されませんが、代わりにチェックサム/MD5アルゴリズムが保存されます。

私たちは今、常に衝突を起こしている。これらの値を保存するための最良の方法は何ですか-元に戻すことはできませんが、将来の値を比較することはできます。

MD5が最適だと思いましたが、ここで議論が続いています...

Answer 1

暗号的に安全なハッシュが機能します。（SHA512またはSHA256で問題ありません）

ただし、カードと一緒に保存されていないかなり秘密の塩を使用します（あらゆる種類のレインボーテーブル攻撃を防ぐため）。

PS：
クレジットカードに対するレインボーテーブル攻撃は、文字セット、固定サイズ、およびチェックディジットが制限されているため、プレーンテキストスペースの合計サイズが非常に小さいため、特に効果的である可能性があります。

PPS：
重複を適切にチェックできないため、エントリごとにランダムなソルトを使用することはできません。ソルトは衝突を防ぐために使用されますが、この場合は特に衝突を探しています。

Answer 2

優れたハッシュアルゴリズムを使用するだけでは十分に安全ではありません。リストが盗まれた場合、保存されているハッシュを使用して、ワーキングカード情報を取得できます。クレジットカード番号の実際のスキーマスペースは十分に小さいため、決定された攻撃者は事前に可能なハッシュの多くを事前に計算できます。これは、侵入や内部ジョブがある場合、システムに他の影響を与える可能性があります。 。

ソルトを使用し、カード番号の各桁と最初のソルト値を含む式に基づいて、ソルトに追加される2番目の値を計算することをお勧めします。これにより、どちらかの部分の制御を失った場合でも、リストの所有権を役に立たなくする合理的な一意性が確保されます。ただし、数式はカードの最初の6桁（BIN番号）に大きく重み付けしないでください。また、数式のトレースをソルトまたは最終ハッシュと同じ場所に保存しないでください。

16桁のクレジットカード番号の構造を考えてみましょう。

6桁のBIN（銀行識別番号）
9桁の口座番号
1桁のLuhnチェックサム

BINリストは処理業界でよく知られており、カード番号の不正なリストにアクセスできる人にとっては、組み立てるのはそれほど難しくありません。有効なBINの数は、各発行者に割り当てられたスペースによってさらに減少します。

Visa-4AmericanExpressで始まります
-34/37MasterCardで
始まります
-5Discover/CUPで始まります-6Diner'sClubで始まります
-35
などで始まります

各発行者カテゴリ内に割り当てられたBIN情報の一部もまばらであることに注意してください。攻撃者がほとんどの顧客の場所を知っている場合、BIN情報は銀行ごとに割り当てられるため、一意性が大幅に低下します。裕福な近所の小さな銀行によって発行されたアカウントをすでに持っている攻撃者は、アカウントを取得して、自分のカードの開始点としてBINを使用する可能性があります。

チェックサムディジットはよく知られた式で計算されるため、一意のデータのソースとしてすぐに破棄できます。

攻撃者は、ターゲティングする価値のある少数のBINを装備しているため、BINセットごとに一度に9桁をチェックする必要があります。これは、1セットあたり10億のチェックサムとハッシュ操作です。便利なベンチマークはありませんが、適切に強力なマシンでのMD5やSHAのフレーバーでは、1分あたり100万回のハッシュ操作が不合理ではないと確信しています。これは、特定のBINの下ですべての一致をクラックするのに1日未満になります。

最後に、タイムスタンプまたはビジタートークン（IP /サブネット）をハッシュと一緒に保存することも検討してください。重複するカード番号を見つけるのは良いことですが、誰かがあなたのシステムに偽のカード番号を詰め込んだ場合の影響も考慮してください。ある時点で、無効であることがわかっているカード番号をブロックすることの間のトレードオフを決定する必要があります。また、誤用を識別して修復するメカニズムを自分自身に与える必要があります。

たとえば、不満を持っている従業員が自分でカード情報を盗んだ後、カード番号のブラックリストに有効なハッシュを挿入して繰り返しのビジネスをブロックすることにより、ハッシュメカニズムを使用することができます。ハッシュを保存するだけの場合、これを元に戻すにはかなりの費用がかかります。ハッシュに変換されると、すべてが不透明になります。これを念頭に置いて、ハッシュのソースも特定する方法を自分に与えてください。

Answer 3

おそらく、カード番号の2つの異なるハッシュを保存できます。両方のハッシュが衝突を引き起こす可能性は事実上ゼロです。

Answer 4

SHA1を使用すると、ハッシュの衝突はまだ検出されていません。

Answer 5

ハッシュが「壊れている」と指摘する人々は、その意味を理解せずに聞いたことを逆流させて、要点を見逃しているのかもしれません。ハッシュが「壊れている」と人々が話すとき、彼らは通常、同じハッシュへの計算を持つ代替ペイロードを簡単に生成できることを意味します。

これはハッシュを「壊す」が、データを検証するためにハッシュを使用するという特定の目的のためだけに、それが想定されているものである。

これはここでは重要ではありません。つまり、クレジットカードの1つと同じ値にハッシュダウンする代替データストリームを作成することに成功した人は、攻撃ベクトルに関して意味のある、または有用なものを何も達成しません。

ここでのハッシュのリスクは、クレジットカード番号の問題スペースがかなり少なく、それらのレインボーテーブルがかなり安価で簡単に生成できることです。

ソルトを追加すると、純粋なカード番号に対してすでに生成されたレインボーテーブルに対する保護が少し追加されますが、実際の保護を提供する範囲は、危険にさらされた場合にソルトがどの程度「秘密」のままであるかによって異なります。塩が露出している場合は、新しいレインボーテーブルを安価に生成でき、すべてが完了します。

ブラックリストに対してチェックを実行するためにアプリケーションがソルトを使用できる必要があることを考えると、ブラックリストデータを侵害している誰かがソルトにアクセスできる可能性が高くなります。複数のサーバーがある場合は、ソルトとデータの両方が同じ「場所」にないようにすることで、ある程度軽減できます。そのため、1つのサーバーが公開されても、必要なすべてのパーツが提供されることはありません。（同様に、バックアップの場合、誰かが1本のテープを持って立ち去ってすべてを入手できる同じメディアにデータとソルトを保存しないでください）。塩はそれが秘密である間だけある程度の保護を追加します（このタイプの使用では）。

安全にそれを行うためのリソースがあれば、それが進むべき道だと思います。妥当なハッシュ関数でかなりの数の衝突が発生している場合は、大量の処理を実行している必要があります。（実際、衝突が問題になることに非常に驚いています。妥当なハッシュ関数であれば、このような小さな問題空間でさまざまな結果が得られるはずです）。

Answer 6

他の人が言っているように、HMACは行くべき道であるべきです。

適切なキーを持つHMAC-SHA-256は、次のようにする必要があります。

1. 衝突を避けてください。
2. 保存された値からクレジットカード番号を取得することは避けてください。
3. 攻撃者が同じ計算を実行するのを防ぎます（一致する値を見つけるために、考えられるすべてのクレジットカード番号に対して）。

しかし、もう1つ非常に重要なことがあります。

クレジットカード番号を保存していないのは当然のことです。適切な暗号化を使用していることを100％確信できたとしても、クレジットカード番号を保存しない可能性があります。なんで？一つには、鍵が漏れる可能性があるためです。

したがって、ハッシュを保存して、クレジットカード番号を取得できないようにします。...右？

プレーンハッシュを使用する場合、考えられるすべてのクレジットカード番号のハッシュを含む単純なレインボーテーブルは、おそらく保存しなかったすべての元のデータを提供します。おっと。しかし、これはあなたが今までに知っていました。

ですから、私たちはもっとうまくやろうとしています。個々の塩を使用する方が優れており、HMACを使用することが私たちが知っている最善のアプローチであるとしましょう。

次のシナリオを検討してください。

• 16桁のカード番号を取ります。
• 最初の6桁（銀行識別番号）は、いくつかの一般的なBINを試すことによって推測されます。
• 最後の4桁は、保存が許可されているマスクされたカード番号に表示されます。（これは保存されていない可能性があります。これは役に立ちます。）
• 1桁が計算されます（Luhn）。

これにより、5桁がブルートフォースされます。それはわずか10万回の試みです。

個々の塩を使用した場合、それはゲームオーバーです。個々のカード番号を平均5万回の試行でブルートフォースすることができます。

HMACを使用したことがあれば、安全であるように見えます。ただし、覚えておいてください...完全に暗号化されていても、キーが漏洩する可能性があるため、暗号化されたカード番号は保存しないことを選択します。何だと思う。私たちのHMACキーも同じように漏洩する可能性があります。このキーを使用すると、平均5万回の試行で、個々のカード番号を総当たり攻撃できます。したがって、漏洩したキーは、暗号化されたカード番号を保存した場合と同じように、クレジットカード番号を提供します。

そのため、クレジットカード番号のエントロピーが低いため、ハッシュを保存しても、暗号化された値と比較してセキュリティはそれほど向上しません（ただし、PCIはキーローテーションの要件を暗号化に制限します）。

少し視点：

わかりました、ここではリークされたキーを想定しています。過激。しかし、繰り返しになりますが、クレジットカード番号の保存を禁止する理由の一部としてPCIも同様であるため、少なくともそれを考慮する必要があります。

確かに、私はBINを見つけるために複数の推測を考慮していませんでした。ただし、これは小さな定数である必要があります。または、1つのBINに制限することもできます。

確かに、PCI監査人は私よりも寛容かもしれません。

はい、マスクされたカード番号を保存しない場合は、1万倍安全です。これは大いに役立ちます。あなたの利点にそれを使用してください。それでも、50Kの試行が実行可能であれば、500Mも実行可能である可能性があります。侵害されたキーのコンテキストで、データを安全であると見なすだけでは十分ではありません。

結論：

HMAC-SHA-256を使用します。リスクを理解します。できるだけ保管しないでください。キーを注意深く保護してください。ハードウェアセキュリティモジュールに大金を費やす:-)

Answer 7

MD5との衝突を見つけた場合は、SHA1やSHA256などのより優れたアルゴリズムを使用してみませんか？

Answer 8

MD5は壊れているので、行く方法ではありません。ブルース・シュナイアーの言葉を引用してください。「MD5が壊れたハッシュ関数であることはすでに知っていました」そして「MD5をもう使うべきではない」。

つまり、誰かがすでに提案したように、SHA512またはSHA256を使用します。

Answer 9

アンリがすでに上で述べたように（+1）、正しい解決策は、秘密鍵でHMACなどのメッセージ認証コードを使用することです。これはまさに前に誰かが言及した「秘密の塩」です。（BTW。ソルトは常に公開されています）。

HMAC-SHA-256（RFC2104、FIPS-198a）などの標準構造を使用し、キーを秘密にして、結果（認証タグ）をデータベースに保存します。

SHA-256のダイジェストサイズ（256ビット）を大きくすると、衝突の発生を防ぐことができます。SHA-256はかなり優れたハッシュ関数であり、ランダムな衝突の確率は2 ^ -128です。したがって、システムで衝突が発生した場合は、私にお知らせください！:)

Answer 10

わざわざ塩を使うのではなく、HMACを使用してください。一種の悪用だとは思いますが、適切なキー付きハッシュを取得するので、衝突やレインボーテーブル攻撃を防ぐことができます。

ここでの良い点は、キーがリークしたとしても、誰もそれを復号化できないことです。HMACで機能する最良の方法は、ブルートフォースです。実は、ここで重要なのは前述の塩です。ここでの良い点は、アルゴリズムがほとんどの非セキュリティプログラマーによって行われる通常のソルティングのものよりも少し優れていることです。

Answer 11

通常、可能な限り強力なハッシュを使用することをお勧めします。速度は重要ではなく、実際には、ハッシュ値をブルートフォースで逆転させようとする人に対して速度が低下します。

私は個人的にワールプールが好きです-PHPを使用している場合は、ハッシュ関数のドキュメントでサポートされているアルゴリズムを確認してください

Whirlpoolは128文字の長さの文字列を返しますが、必ずしもすべてを格納する必要はありません。最初の32文字または64文字で十分です。また、sha512またはsha284を検討することもできます。