同じクレジット カード番号が 2 つの異なるアカウントに登録されないようにしたいシステムがあります。クレジット カード番号は内部に保存されないため (下 4 桁と有効期限のみ)、単純にクレジット カード番号と有効期限を比較することはできません。
現在のアイデアは、カードの登録時にクレジット カード情報のシステムにハッシュ (SHA-1) を保存し、ハッシュを比較してカードが以前に使用されたかどうかを判断することです。
通常、salt は辞書攻撃を回避するために使用されます。この場合、私たちは脆弱であると想定しているため、ハッシュとともにソルトを保存する必要があります。
この方法に欠陥はありますか？これは、この問題を解決する標準的な方法ですか?
少し計算してみましょう。クレジット カード番号は 16 桁です。最初の 7 桁は「主要な業界」と発行者番号で、最後の桁は luhn チェックサムです。これにより、合計 100,000,000 のアカウント番号に対して 8 桁の「空き」が残り、潜在的な発行者番号の数 (これは非常に高くなる可能性は低い) を掛けたものになります。日常のハードウェアで毎秒数百万のハッシュを実行できる実装があるため、どのようなソルティングを行っても、ブルート フォースにとっては大した問題にはなりません。
偶然にも、ハッシュ アルゴリズムのベンチマークを提供するものを探していたときに、クレジット カード ハッシュの保存に関する次の記事を見つけました。
ハッシュ アルゴリズムの単純なシングル パスを使用してクレジット カードを保存することは、ソルトされている場合でも非常に困難です。ハッシュが侵害された場合、クレジットカード番号を総当たりするのは非常に簡単です.
...
クレジット カード番号をハッシュする場合、利用可能な最強の暗号化ハッシュ関数、大きなソルト値、および複数回の反復を使用して、ブルート フォースから保護するようにハッシュを慎重に設計する必要があります。
記事全体は十分に読む価値があります。残念ながら、結果として、ハッシュ化されたクレジット カード番号を保存することが「安全」になる状況では、重複を検索するのに法外なコストがかかるようです。
人々はこれのデザインを考えすぎていると思います。sha-256 のようなソルトされた、非常に安全な (たとえば、「計算コストが高い」) ハッシュを、レコードごとに一意のソルトで使用します。
最初に低コストで高精度のチェックを行い、そのチェックがヒットした場合にのみ高コストの決定的なチェックを行う必要があります。
ステップ1：
最後の 4 桁に一致するものを探します (また、場合によっては有効期限も検索しますが、対処が必要な場合があります)。
ステップ2：
単純なチェックがヒットした場合は、salt を使用してハッシュ値を取得し、詳細なチェックを行います。
cc# の最後の 4 桁は最も一意であるため (LUHN チェック ディジットも含まれているため)、最終的に一致しない詳細なチェックの割合 (誤検知率) は非常に高くなります。非常に低い (数パーセント) ため、単純な「毎回ハッシュ チェックを行う」設計と比較して、膨大な量のオーバーヘッドを節約できます。
クレジットカード番号の単純なSHA-1を保存しないでください。解読するのは非常に簡単です（特に最後の4桁がわかっているため）。私の会社でも同じ問題がありました。これが私たちがそれを解決した方法です。
最初の解決策
hash(stored_CC1_salt+CC2)==stored_CC1_hashます。データベースには約10万枚のクレジットカードがあるため、約10個のハッシュを計算する必要があり、約10秒で結果が得られます。私たちの場合、これは問題ありませんが、bcryptを少し調整することをお勧めします。残念ながら、そうすると、このソリューションの安全性は低下します。一方、bcryptをさらにCPUを集中的に使用するように調整すると、CC番号の照合に時間がかかります。
このソリューションは、CC番号の無塩ハッシュを単に保存するよりもはるかに優れていると思いますが、意欲的な海賊（データベースのコピーを取得することに成功）が平均して1枚のクレジットカードを破るのを防ぐことはできません。 2〜5年。したがって、データベースに10万枚のクレジットカードがあり、海賊がCPUを大量に持っている場合、海賊は毎日数枚のクレジットカード番号を回復できます。
これは、ハッシュを自分で計算するべきではないという信念につながります。それを他の誰かに委任する必要があります。これは2番目のソリューションです（この2番目のソリューションに移行中です）。
2番目の解決策
支払いプロバイダーにクレジットカードのエイリアスを生成させるだけです。
シンプルで、高速で、安全です（少なくとも、支払いプロバイダーがそうであれば）。私が見る唯一の問題は、それがあなたをあなたの支払いプロバイダーに結びつけるということです。
お役に立てれば。
PCI DSSは、強力な一方向ハッシュを使用して PAN (クレジット カード番号) を保存できると述べています。塩漬けにする必要さえありません。つまり、カードごとに一意の値でソルトする必要があります。有効期限は良いスタートですが、少し短すぎるかもしれません。発行者など、カードの他の情報を追加することもできます。CVV/セキュリティ番号は保管が許可されていないため、使用しないでください。有効期限を使用すると、カード所有者が同じ番号の新しいカードを発行されたときに、別のカードとしてカウントされます。これは、要件に応じて、良いことにも悪いことにもなります。
データをより安全にするアプローチは、各操作の計算コストを高くすることです。たとえば、md5 を 2 回実行すると、攻撃者がコードを解読するのに時間がかかります。
有効なクレジット カード番号を生成し、考えられる有効期限ごとに課金を試みるのは、ごく簡単なことです。ただし、計算コストが高くなります。ハッシュをクラックするコストを高くすると、誰も気にする価値がなくなります。ソルト、ハッシュ、および使用したメソッドがあったとしても。
@Cory R. King
SHA1自体は壊れていません。この記事が示しているのは、ブルートフォース時間未満で同じハッシュ値を持つ2つの文字列を生成できることです。それでも、妥当な時間内にSPECIFICハッシュに相当する文字列を生成することはできません。2つの間に大きな違いがあります。
ハッシュを比較することは良い解決策です。ただし、すべてのクレジットカード番号を同じ一定のソルトでソルトしないようにしてください。カードごとに異なる塩（有効期限など）を使用してください。これにより、辞書攻撃に対してかなり不浸透性になります。
保存する各パスワードに、長くて一意のランダムソルトを追加します。ソルト（または必要に応じてナンス）のポイントは、ブルートフォース攻撃が時間の無駄になるように、各パスワードを一意で十分な長さにすることです。したがって、ユーザーのパスワードは、「myspace1」のハッシュとして保存されるのではなく、128文字のランダムなUnicode文字列+「myspace1」のハッシュとして保存されることになります。これで、レインボーテーブル攻撃の影響を完全に受けなくなります。
ほとんど良い考えです。
ハッシュだけを保存することは良い考えです、それは何十年もの間パスワードの世界で役立ってきました。
ソルトを追加することは公正な考えのように思われ、実際、ブルートフォース攻撃は攻撃者にとってはるかに困難になります。ただし、新しいCCが一意であることを実際に確認する場合、そのソルトには多くの余分な労力がかかります。新しいCC番号をN回SHA-1する必要があります。ここで、Nはソルトの数です。比較しているすべてのCCですでに使用されています。確かにあなたが良いランダムソルトを選ぶなら、あなたはあなたのシステムの他のすべてのカードのためにハッシュをしなければならないでしょう。だから今、それはあなたが力任せをしているのです。したがって、これはスケーラブルなソリューションではないと思います。
ご覧のとおり、パスワードの世界では、この特定のユーザー用に保存したものにクリアテキスト+ソルトハッシュがあるかどうかを知りたいだけなので、ソルトはコストを追加しません。あなたの要件は実際にはかなり異なります。
トレードオフを自分で検討する必要があります。ソルトを追加しても、データベースが盗まれてもデータベースは安全になりません。データベースのデコードが難しくなるだけです。どれくらい難しいですか？攻撃が30秒から1日かかるように変更された場合、何も達成されていません。それでもデコードされます。それが1日から30年に変わるなら、あなたは検討する価値のある何かを達成しました。
上記で示唆したように、良い解決策は、たとえばカード番号、有効期限、名前などのハッシュ値を保存することだと思います。そうすれば、まだ簡単な比較を行うことができます...
ここでは、 Sha1の破損は問題ではありません。壊れた手段はすべて、予想よりも簡単に衝突（同じsha1を持つ2つのデータセット）を計算できることです。これは、sha1に基づいて任意のファイルを受け入れる場合に問題になる可能性がありますが、内部ハッシュアプリケーションとは関係ありません。
ソルトハッシュは問題なく機能するはずです。ユーザーごとのソルトシステムを使用すると、十分なセキュリティが確保されます。
SHA1が壊れています。もちろん、良い代替品が何であるかについての情報はあまりありません。SHA2？
Stripe / Braintree などの支払い処理業者を使用している場合は、彼らに「重い仕事」を任せてください。
どちらも、データベースに安全に保存し、後で比較してカードが既に存在するかどうかを確認できるカードフィンガープリントを提供します。
fingerprint文字列を返します -ドキュメントを参照してくださいunique_number_identifier string-ドキュメントを参照してくださいカード番号の下 4 桁をカード所有者の名前 (または姓のみ) および有効期限と組み合わせると、記録を一意にするのに十分な情報が得られます。ハッシュはセキュリティに優れていますが、重複チェックのためにハッシュを複製するためにソルトを保存/呼び出す必要はありませんか?
はい、この場合、ハッシュの比較はうまくいくはずです。