私はすでに塩漬けハッシュを使用してデータベースにパスワードを保存しています。つまり、レインボー テーブル攻撃の影響を受けないはずです。
しかし、私は考えました: 誰かが私のデータベースを手に入れたらどうしますか? ユーザーの電子メールアドレスが含まれています。これらを使用して通知メールなどを送信するため、これらを実際にハッシュすることはできません..
それらを暗号化する必要がありますか？
21399 次
11 に答える
61
Bruce Schneier は、この種の問題にうまく対応しています。
暗号化はセキュリティ問題の解決策ではありません。それは解決策の一部かもしれませんし、問題の一部かもしれません。多くの場合、暗号化は問題を悪化させることから始まり、暗号化を使用することが改善につながるかどうかはまったく明らかではありません。
「万が一に備えて」データベース内の電子メールを本質的に暗号化しても、実際にはデータベースがより安全になるわけではありません。データベースのキーはどこに保存されますか? これらのキーにはどのようなファイル許可が使用されていますか? データベースはパブリックにアクセスできますか? なんで？これらのアカウントには、どのような種類のアカウント制限がありますか? マシンはどこに保管されていますか? このボックスに物理的にアクセスできるのは誰ですか? リモートログイン/ sshアクセスなどについてはどうでしょうか。
したがって、必要に応じて電子メールを暗号化することもできると思いますが、それがシステムのセキュリティの範囲である場合、実際にはあまり効果がなく、実際にはデータベースを維持する仕事が難しくなります.
もちろん、これはシステムの広範なセキュリティ ポリシーの一部である可能性があります。
私はそれが悪い考えだと言っているわけではありません - しかし、ドアの周りの合板を切り抜けることができるのに、5000 ドルもする Deadlocks'R'us のドアにロックを掛けるのはなぜですか? それとも開けっ放しの窓から入ってくるの？さらに悪いことに、彼らはドアマットの下に残された鍵を見つけます。システムのセキュリティは、最も弱いリンクと同程度です。root アクセス権があれば、ほとんどのことを実行できます。
Steve Morganは、電子メール アドレスを理解できなくても、多くの害を及ぼす可能性があることを適切に指摘しています (これは、SELECT アクセスのみを持っていれば軽減できます)。
メールアドレスを保存する理由を知ることも重要です。この回答で少しやり過ぎたかもしれませんが、私のポイントは、アカウントのメールアドレスを本当に保存する必要があるということです? 最も安全なデータは、存在しないデータです。
于 2008-09-16T09:00:17.790 に答える
20
これが死んだ話題であることは理解していますが、この背後にある Arjan の論理には同意します。私が指摘したいことがいくつかあります:
ソース コードを取得せずに、誰かがデータベースからデータを取得できます (つまり、SQL インジェクション、サード パーティのデータベース)。これを念頭に置いて、鍵による暗号化の使用を検討することは合理的です。とはいえ、これはセキュリティの追加手段に過ぎず、セキュリティではありません...これは、電子メールをプレーンテキストよりもプライベートに保ちたい人向けです。万が一、
更新中に何かが見落とされたり、攻撃者がなんとかしてメール。
IMO:メールを暗号化する予定がある場合は、ソルト付きハッシュも保存してください。次に、検証にハッシュを使用し、大量のデータ文字列を見つけるために常に暗号化を使用するオーバーヘッドを節約できます。次に、メールを使用する必要があるときにメールを取得して復号化するための別のプライベート関数を用意します.
于 2012-08-12T16:57:33.720 に答える
12
ほとんどのセキュリティ要件と共通して、脅威のレベルを理解する必要があります。
電子メールアドレスが危険にさらされた場合、どのような損害が発生する可能性がありますか？
それが起こる可能性は何ですか？
電子メールアドレスが置き換えられた場合の被害は、公開された場合よりもはるかに大きくなる可能性があります。特に、たとえば、電子メールアドレスを使用して、安全なシステムへのパスワードのリセットを確認している場合。
パスワードをハッシュすると、パスワードが置き換えられたり公開されたりする可能性は大幅に減少しますが、他にどのようなコントロールを使用しているかによって異なります。
于 2008-09-16T08:53:42.623 に答える
7
データベースのアプリケーションに依存すると思います。
最大の問題は、暗号化キーをどこに保管するかということです。ハッカーがあなたのデータベース以上のものを持っている場合、あなたのすべての努力はおそらく無駄になるからです. (アプリケーションは暗号化解除と暗号化にその暗号化キーを必要とするため、最終的にハッカーは暗号化キーと使用された暗号化スキームを見つけます)。
プロ：
- DB のリークだけでは、電子メール アドレスは公開されません。
短所：
- 暗号化はパフォーマンスの低下を意味します。
- データベース アクションの割り当ては、不可能ではないにしても難しくなります。
于 2008-09-16T08:58:10.400 に答える
4
Don't accidentally conflate encryption with obfuscation. We commonly obfuscate emails to prevent spam. Lots of web sites will have "webmaster _at_ mysite.com" to slow down crawlers from parsing the email address as a potential spam target. That should be done in the HTML templates -- there's no value to doing this in persistent database storage.
We don't encrypt anything unless we need to keep it secret during transmission. When and where will your data being transmitted?
The SQL statements are transmitted from client to server; is that on the same box or over a secure connection?
サーバーが侵害された場合、意図しない送信が発生します。これが心配な場合は、おそらくサーバーを保護する必要があります。内部の脅威だけでなく、外部の脅威もあります。すべてのユーザー (外部および内部) が適切に認証および承認されていますか?
バックアップ中に、バックアップ メディアへの意図的な送信があります。これは、進行中に暗号化する安全なバックアップ戦略を使用して行われますか?
于 2008-09-16T10:17:18.650 に答える
3
ユーザーの電子メールアドレスをデータベースに保存するための最良かつ最も安全な方法は何ですか?での私の回答のコピー 、検索のためだけに...
一般的に、努力する価値がないと言う他の人に同意します。ただし、あなたのデータベースにアクセスできる人なら誰でもあなたの鍵を取得できる可能性があるという意見には同意しません。これは、SQL インジェクションには当てはまりません。また、何らかの理由で紛失または忘れられたバックアップ コピーには当てはまらない可能性があります。また、メール アドレスは個人的な情報だと感じているので、スパムは気にしませんが、アドレスが公開された場合の個人的な影響については気にします。
もちろん、SQL インジェクションが怖い場合は、そのようなインジェクションが禁止されていることを確認する必要があります。また、バックアップ コピー自体も暗号化する必要があります。
それでも、一部のオンライン コミュニティでは、メンバーは他の人に自分がメンバーであることを絶対に知られたくない場合があります (メンタル ヘルスケア、経済的支援、医療および性に関するアドバイス、アダルト エンターテイメント、政治などに関連するものなど)。そのような場合、できるだけ少ない個人情報を保存し、必要な情報を暗号化すること (データベース レベルの暗号化は、SQL インジェクションを使用して詳細が表示されるのを妨げないことに注意してください) は、それほど悪い考えではないかもしれません。繰り返しますが、電子メール アドレスは個人情報として扱います。
多くのサイトでは、おそらく上記のことは当てはまらないため、SQL インジェクションによる禁止に注力しSELECT * FROM、訪問者が URL を変更して他人の個人プロファイルや注文情報にアクセスできないようにする必要があります。
于 2009-04-20T18:21:07.700 に答える
2
データベース内のデータを暗号化することは価値があります。少し難しくなるわけではありませんが、適切な方法で暗号化されている場合ははるかに難しくなるため、哲学をやめて機密データを暗号化してください;)
于 2014-09-01T19:07:11.583 に答える
2
SQL Server と Oracle の両方 (および他の DB もそうだと思います) は、データベース レベルでのデータの暗号化をサポートしています。何かを暗号化したい場合は、データベースサーバー側で暗号化できるデータへのアクセスを単純に抽象化し、暗号化されたデータを使用するかどうかをユーザーに選択させないでください (この場合、SQL コマンドは異なります)。ユーザーが暗号化されたデータを使用したい場合は、データベースサーバーを構成できます。キー管理に関連するすべてのメンテナンス作業は、あなたではなく DB ベンダーから作成された標準の DBA ツールを使用して行われます。
于 2008-09-16T10:13:41.420 に答える
1
@ルー
私はあなたの言っていることにある程度同意しますが、データを暗号化して、誰かがデータを取得するのを少し難しくするだけの価値はありませんか?
あなたの推論では、家に鍵やアラームを設置しても意味がありません。それらも簡単に侵害される可能性があるからです。
私の返事:
機密データが悪用されたくない場合は、100% 絶対確実でなくても、ハッカーが入手できるようにできる限りのことを行う必要があります。
于 2008-09-16T09:08:48.237 に答える
0
誰かがそれらの電子メールアドレスを取得するという最悪のシナリオ、誰かがそれらを取得する可能性、および変更を暗示するために必要な余分な労力/時間を実際に比較検討する必要があります。
于 2008-09-16T08:51:58.963 に答える
0
ここで重要な答えが 1 つ欠けています。ヨーロッパのユーザーがいる場合、GDPR 規則に準拠する必要があります。電子メール アドレスは個人データと見なされます。つまり、第 5 条が電子メール アドレスに適用されます。
適切な技術的または組織的手段を使用して、無許可または違法な処理に対する保護、および偶発的な損失、破壊、または損傷に対する保護を含む、個人データの適切なセキュリティを確保する方法で処理されます (「完全性および機密性」)。
もちろん、これは電子メール アドレスを暗号化する必要があると言っているわけではありません。しかし、データを暗号化することで、従業員のスヌーピングからデータを保護できます。また、開発者として、データベースを手動で変更する要求から身を守ります。
于 2021-02-19T10:03:34.643 に答える