クレジット カード暗号化に最適な .NET アルゴリズムはありますか?
https://stackoverflow.com/questions/41220
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
ネット System.Security.Cryptography 名前空間には、クレジット カードの詳細の暗号化に使用できる、かなり不可解なアルゴリズムのコレクションが含まれています。どちらがベストか？
比較的短い文字列に対しては明らかに安全である必要があります。
編集：私は英国にいますが、3 桁の CVV 番号が決して保存されない限り、暗号化されたクレジット カードの詳細を保存しても問題ないと理解しています。そして素晴らしい回答をくださった皆様、ありがとうございました。
解決
悪気はありませんが、質問は少し「見当違い」です。「特効薬」の解決策はありません。暗号化全般について読んでから、脅威のモデリングを行うことをお勧めします。自問すべきいくつかの質問 (決して包括的なリストではありません):
- 暗号化を実行しているモジュールは、それを復号化する必要があるモジュールですか (この場合は対称暗号を使用します)、それともそれを使用する他のモジュール (別のマシン上) にデータを送信しますか (その場合、公開鍵を考慮する必要があります)暗号通貨）
- 何から守りたいですか？誰かがデータベースにアクセスしているが、ソースコードを持っていない (この場合、暗号化キーをソースに直接ハードコーディングできます)?誰かがローカル ネットワークを盗聴していますか (IPSec のような透過的なソリューションを検討する必要があります)?誰かがあなたのサーバーを盗みますか (データセンターでも起こる可能性があります。その場合はフルディスク暗号化を検討する必要があります)?
- 本当にデータを保持する必要がありますか?クレジットカード処理業者に直接渡して、確認が取れたら消去することはできないのでしょうか？Cookie または Flash LSO でクライアントのローカルに保存することはできませんか?クライアントに保存する場合は、Cookie に入れる前に必ずサーバー側で暗号化してください。また、Cookie を使用している場合は、必ず http のみにしてください。
- データの同等性を比較するだけで十分ですか (つまり、クライアントが私に提供したデータは私が持っているデータと同じです)。その場合は、そのハッシュを保存することを検討してください。クレジット カード番号は比較的短く、使用されるシンボルのセットが少ないため、ハッシュ化する前にそれぞれに一意のソルトを生成する必要があります。
後で編集する:同じカテゴリの標準暗号化アルゴリズム (たとえば、3DES と AES、どちらも対称ブロック暗号) は同等の強度であることに注意してください。ほとんどの (商用) システムが壊れるのは、誰かが暗号化をブルートフォースしたからではなく、脅威のモデリングが十分に詳細ではなかった (または、完全に何もしていなかった) ためです。たとえば、すべてのデータを暗号化することはできますが、SQL インジェクションに対して脆弱な公開 Web インターフェイスを使用している場合は、あまり役に立ちません。
他のヒント
それは関係ないよ。
完全なカード番号がディスクに触れないようにしてください。
重要なのは認証コードだけです。
トレースなどには、最後の 4 桁 xxxx xxxx xxxx 1234 と有効期限日のみを使用します。
カード番号を保存する場合、暗号化の選択は取得する銀行によって義務付けられます。
あなたが買収者でない限り、その場合は、古い UNIX プログラマ/DB2 担当者に尋ねるべきです。
「Cookie でクライアントのローカルに保存できないか」 <-- 絶対に保存しないでください
私は、本当に正当な理由がない限り、それらを保存すべきではなく、クッキーに保存するのは危険であるという見解に付け加えます。 本当に 悪い考え - 彼らはただの 簡単すぎる (誰かが Cookie を盗んだ場合はどうなりますか。その場合、Cookie がどれほど暗号化されているかは関係ありません)。
繰り返し支払いを行う必要がある場合、ほとんどの CC プロバイダーは、カード番号をまったく保持せずに、最初の支払いから何らかのトークンを保存することでこれを行う方法を提供します (顧客に表示するために最後の 4 桁だけを保持することもできます)どのカードが保管されているかがわかるようにするため）。
本当に、それはやめてください！
また、CCV コードは決して保管しないでください。
とおり PCI DSS コンプライアンス ルールに準拠している場合は、業界をリードする暗号化標準であればどれでも十分です。したがって、256 ビット キーを備えた 3DES で十分です (ただし、他の標準も使用できます)。これをチェックしてください http://pcianswers.com/2006/08/09/methods-of-encrypting-data/
ここでは誠実さを忘れないでください。攻撃者がキーを知らなくても暗号文を操作できる場合、すぐに使用できる暗号に対する偽造攻撃が存在します。これらは、次の場合に特に厄介になる可能性があります。
- 短い文字列の暗号化、
- 既知の部分文字列を含む
まさにクレジットカードの場合がそうです。したがって、独自のチェックサムをロールせずに CBC モードで System.Security.Cryptography AES または 3DES を使用することは危険な可能性があります。読む：秘密キーを持たない攻撃者がクレジット カード番号を別の番号に置き換える可能性があります。
サードパーティの支払いゲートウェイを使用している場合は、番号を保存する必要はありません。
意味はありません。
3des は非常に優れており、ソルトも一緒に保存し、標準キーをデータベースや設定ファイル以外の場所に保存します。そうすれば、あなたが pwn された場合でも、彼らはそれを復号化できなくなります。
法的な側面も考慮する必要があります。他の国の状況は知りませんが、ドイツではクレジットカード番号を保存することは単純に許可されていません1). 期間。 暗号化するかどうかや、どのような形式で保存するかは関係ありません。
皆さん 5月 (ここでは司法知識なしで記憶だけで言及していますが) クレジット カード番号の強力なハッシュ (SHA-256?) と、最後の 4 桁および口座番号を保存します。確かに、これらの情報だけから完全な数値を再構築するのは簡単です。法律は必ずしも論理的であるとは限りません。
1) ただし、連邦政府に認定されたクレジット カード機関である場合は除きます。
ヒント： クレジット カード番号を保存することが合法かどうかを調査する必要があります。たとえばスウェーデンでは、次の認定を受ける必要があります。 PCI (ペイメントカード業界), 、内部および外部のセキュリティがテストされます（他の多くのことと長いです）。
クレジット カード情報を保存する前に、両方のことを 1 ～ 2 回検討する必要があります。間違った行為をすると法的費用が高額になる可能性があるためです。
クレジット カードを公開キーで暗号化します。秘密キーは支払い処理マシンにのみ与えてください。その後、支払い処理マシンはデータベースにクエリを実行して作業を行うことができ、エントリを追加したマシンであっても、他の誰もそれを解読できなくなります。
PHP の openssl_seal のようなものですが、必要に応じて別のアルゴリズムを使用することもできます。
