2

私はセキュリティの第一人者ではありません。クレジット カードのトランザクションが Web 経由で受け入れられるが、社内ユーザーによって手動で実行されるソフトウェア システムにクレジット カード ストレージを実装する方法を考えています。中間者攻撃のリスクを排除する (私が信じている) HTTPS を使用します。現在、クライアントから受信したデータがサーバーに到達する前に暗号化できるようにできるかどうかを調べています。

アイデアは、ブラウザが非対称キー ペアの公開部分を使用してデータを暗号化するというものです。プライベートな部分は社内ユーザーに知られます。その後、請求を手動で処理するときが来たら、そのユーザーは Google が提供する HTTPS ページに移動します。彼らは秘密鍵を手動で入力し (サーバーには送信されません)、暗号化されたクレジット カード情報がシステムから取得され、ブラウザーによって復号化されます。

このようにして、どのサーバーにも暗号化されていないクレジット カード情報が表示されないようにできることを願っています。よく知られているセキュリティ ホールを見逃していませんか? これを読んだことがありますが、これは別の種類のセキュリティ ホールに対処しているようです。他のSOの質問もいくつか読みましたが、この特定の設計に明確に対応しているようには見えません。

編集 #1: @Pointy は、業界標準を使用しない理由を尋ねました。主要なオンライン小売業者は、私の問題が保証するよりもはるかに洗練された高価なソリューションを使用しています. 主要な小売業者は取引を自動的に処理するため、通常は PCI-DSS 準拠に取り組んでいます。これは私が解決しようとしている問題ではありません。私は、手動のトランザクション処理を安全に支援するための自動ツールに取り組んでいます。

編集 #2: @Jason Dean は、秘密鍵を管理するための計画をうまく説明していないと指摘しました。アイデアは、文字通り、従業員が机の上に一枚の紙に置いてもらうことです. 私たちの主な関心事は、リモートのセキュリティ違反です。私たちの物理的なサイトは十分に安全なので、誰かが侵入する心配はありません。アイデアは、純粋に電子的な攻撃がデータと秘密の両方を取得できないように、秘密鍵をどこのマシンの永続的なストレージにも入れないようにすることです。鍵。

4

2 に答える 2

2

彼らは秘密鍵を手動で入力し (サーバーには送信されません)、暗号化されたクレジット カード情報がシステムから取得され、ブラウザーによって復号化されます。

クレジット カード番号を単純に入力するよりも、セキュリティを確保して秘密鍵を入力 (またはコピー/貼り付け) する方が難しいでしょう。私はこれをあなたのスキームの明らかな間違いと呼んでいます。セキュリティプロトコルは難しいことに注意してください。あなたは「セキュリティの第一人者ではない」ので、考えようとしないことを強くお勧めします。

于 2012-10-23T21:58:17.693 に答える
1

暗号化されていないデータがサーバーに表示されることを非常に懸念しているのに、重要なすべての暗号化解除キーを、あなたが入力する (より具体的にはコピー アンド ペーストする) ことを決定した 1 時間あたり 8 ドルのモンキーに喜んで提供するのは興味深いことです。一日中鍵。

これらのキーをどこに保管して、サルがコピー/貼り付けのためにアクセスできるようにする予定ですか? そのためには、平文である必要があります。

鍵の管理は、間違いなく暗号化で最も難しいことであり、鍵を必要としないユーザーが鍵を利用できるようにし、安全に保管しないことで、ベスト プラクティス プロトコルに違反することについて話しているのです。

SSL は、クライアントを離れる前にデータを暗号化します。サーバーに到達したら、データを保存する前に再度暗号化する必要があります。本当に必要な場合は、非対称暗号を使用できます。私はクライアントでそれをしようとすることを心配しません。

あなたは必要以上に物事を難しくしていると思いますが、あなたの努力には何のメリットもありません。

于 2012-10-23T22:06:33.130 に答える