8

.NETSystem.Security.Cryptography名前空間には、クレジット カードの詳細を暗号化するために使用できる、かなり当惑するようなアルゴリズムのコレクションがあります。どちらがベストか？

比較的短い文字列の場合、明らかに安全である必要があります。

編集: 私は英国にいますが、3 桁の CVV 番号が決して保存されない限り、暗号化されたクレジット カードの詳細を保存しても問題ないことを理解しています。そして、すばらしい回答をありがとうございました。

4

10 に答える 10

24

問題はありませんが、質問は少し「見当違い」です。「銀の弾丸」ソリューションはありません。暗号化全般について読んでから、脅威のモデル化を行うことをお勧めします。自問すべきいくつかの質問 (決して包括的なリストではありません):

  • 暗号化を行っているモジュールは、それを復号化する必要があるモジュールですか (この場合は対称暗号を使用します)、またはそれを使用する別のモジュール (別のマシン上の) にデータを送信しますか (この場合、公開鍵を検討する必要があります)。暗号)
  • 何から守りたいですか？データベースにアクセスしているが、ソースコードを持っていない人 (この場合、暗号化キーをソースに直接ハードコーディングできます)? 誰かがローカル ネットワークを盗聴していませんか (IPSec のような透過的なソリューションを検討する必要があります)。誰かがあなたのサーバーを盗んでいますか (データセンターでも発生する可能性があります。この場合、ディスク全体の暗号化を検討する必要があります)。
  • 本当にデータを保持する必要がありますか? クレジットカード会社に直接渡して、確認が取れてから消せませんか？Cookie または Flash LSO のクライアントでローカルに保存できませんか? クライアントに保存する場合は、Cookie に入れる前にサーバー側で暗号化してください。また、Cookie を使用している場合は、必ず http のみにしてください。
  • データの同等性を比較するだけで十分ですか (つまり、クライアントから提供されたデータは、私が持っているデータと同じですか)? その場合は、そのハッシュを保存することを検討してください。クレジット カード番号は比較的短く、少数のシンボル セットを使用するため、ハッシュする前にそれぞれに対して一意のソルトを生成する必要があります。

後で編集: 同じカテゴリの標準暗号化アルゴリズム (たとえば、3DES と AES - どちらも対称ブロック暗号) は同等の強度であることに注意してください。ほとんどの (商用) システムは、誰かが暗号化を強引に行ったために壊れたのではなく、脅威のモデル化が十分に詳細に行われていなかった (または完全に何もなかった) ためです。たとえば、すべてのデータを暗号化できますが、SQL インジェクションに対して脆弱な公開 Web インターフェイスを使用している場合、あまり役に立ちません。

于 2008-09-03T06:02:00.323 に答える
12

それは問題ではありません。

完全なカード番号は決してディスクに触れてはいけません。

重要なのは認証コードです。

トレースなどの場合は、最後の4桁のxxxx xxxxxxxx1234と有効期限のみを使用します。

カード番号を保存する場合、暗号化の選択は取得銀行によって義務付けられます。

あなたが取得者でない限り、その場合、あなたが尋ねるべき古いunixプログラマー/db2の人がいるはずです。

「クライアントのCookieにローカルに保存することはできません」<-決して

于 2008-09-04T08:40:19.687 に答える
7

本当に正当な理由がない限り、単純に保存するべきではないという見方を付け加えておきます。Cookieに保存するのは非常に悪い考えです。簡単に手に入れることができません（何誰かがCookieを盗んだ場合に発生します-それがどれほど暗号化されているかは関係ありません）。

繰り返し支払いを行う必要がある場合、ほとんどのCCプロバイダーは、カード番号をまったく保持せずに、最初の支払いから何らかのトークンを保存することでこれを行う方法を提供します（顧客に表示するために最後の4桁を保持することができます）どのカードが保存されているかがわかるようにします）。

本当に、それをしないでください！

また、CCVコードを保持することは絶対にしないでください。

于 2008-09-04T09:24:39.393 に答える
5

PCI DSSコンプライアンス ルールに従って、業界をリードする暗号化標準で十分です。したがって、256 ビットのキーを使用する 3DES で十分です (ただし、他の標準を使用することもできます)。これをチェックしてくださいhttp://pcianswers.com/2006/08/09/methods-of-encrypting-data/

于 2008-09-03T06:13:37.723 に答える
1

ここで完全性を忘れないでください。攻撃者がキーを知らないが、暗号文を操作できる場合、すぐに使用できる暗号に対する偽造攻撃があります。これらは、次の場合に特に厄介になる可能性があります。

  • 短い文字列の暗号化、
  • 既知の部分文字列

それはまさにクレジットカードの場合です。したがって、独自のチェックサムをロールせずにSystem.Security.Cryptography AESまたは3DESをCBCモードで使用すると、危険な場合があります。読む：秘密鍵を持たない攻撃者が、あるクレジットカード番号を別のクレジットカード番号に置き換える可能性があります。

于 2008-09-05T00:30:29.013 に答える
1

サード パーティの支払いゲートウェイを使用している場合は、番号を保存する必要はありません。

意味はありません。

于 2008-09-06T16:04:52.860 に答える
0

考慮すべき法的側面もあります。他の場所の状況はわかりませんが、ドイツではクレジットカード番号を保存することは許可されていません1）。限目。それらを暗号化するかどうか、およびどの形式で保存するかは関係ありません。

クレジットカード番号の強力なハッシュ（SHA-256？）を、最後の4桁とアカウント番号とともに保存するだけで、（ここでは、司法の知識がなくても、メモリから参照できます）実行できます。そして、はい、これらの情報だけから完全な数を再構築することは簡単です。法則は必ずしも論理的ではありません。

1）連邦政府が認定したクレジットカード機関の場合を除きます。

于 2008-09-04T09:00:11.450 に答える
0

ヒント：クレジットカード番号を保存することが合法かどうかを調査する必要があります。たとえばスウェーデンでは、 PCI（Payment Card Industry）の認定を受ける必要があります。そこでは、内部および外部のセキュリティがテストされます（他にも多くのことがあります）。

クレジットカード情報を保存する前に、1回か2回の両方を検討する必要があります。これを間違えると、訴訟費用が高くつく可能性があるためです。

于 2008-09-04T09:10:25.667 に答える
0

クレジット カードを公開鍵で暗号化します。秘密鍵は、支払い処理マシンにのみ渡してください。その後、支払い処理マシンはデータベースにクエリを実行して作業を行うことができ、他の誰も、エントリを追加したマシンであっても、それを解読することはできません.

PHP の openssl_seal のようなものですが、必要に応じて別のアルゴリズムを使用することもできます。

于 2011-01-22T07:24:11.003 に答える
0

3des は非常に優れており、salt を一緒に保存し、データベースや構成ファイル以外の場所に標準キーを保持します。そうすれば、あなたが乗っ取られた場合、彼らはそれを解読できません.

于 2008-09-03T05:48:20.170 に答える