私はすでに ソルトハッシュ を使用してパスワードをデータベースに保存しています。つまり、 レインボーテーブル 攻撃の影響を受けないようにする必要があります。
しかし、私は考えました。誰かが私のデータベースを手に入れたらどうなるでしょうか。ユーザーのメールアドレスが含まれています。通知メールなどを送信するために使用するため、実際にハッシュすることはできません。
それらを暗号化する必要がありますか?
ブルース・シュナイアーは、この種の問題に対して優れた対応をしています。
暗号化はセキュリティ問題の解決策ではありません。それは解決策の一部であるか、問題の一部である可能性があります。多くの場合、暗号化は問題を悪化させることから始まりますが、暗号化を使用することが改善であるかどうかはまったく明らかではありません。
基本的に、データベース内の電子メールを「万が一に備えて」暗号化しても、データベースの安全性が実際に向上するわけではありません。データベースのキーはどこに保存されていますか?これらのキーにはどのファイル権限が使用されていますか?データベースは公的にアクセス可能ですか?どうして?これらのアカウントにはどのようなアカウント制限がありますか?このボックスに物理的にアクセスできるマシンはどこに保管されていますか?リモートログイン/ sshアクセスなどはどうですか?.
したがって、必要に応じて電子メールを暗号化できると思いますが、それがシステムのセキュリティの範囲である場合、実際にはそれほど多くのことを行っておらず、実際にはデータベースの保守作業が難しくなります。
もちろん、これはシステムの広範なセキュリティポリシーの一部である可能性があります。そうであれば、すばらしいことです。
それが悪い考えだと言っているのではありませんが、ドアの周りの合板を切り裂くことができるのに、なぜDeadlocks'R'usのドアに5000ドルかかるロックがあるのでしょうか。それとも、開いたままにした窓から入って来ますか?さらに悪いことに、彼らは玄関マットの下に残された鍵を見つけます。システムのセキュリティは、最も弱いリンクと同じくらい良いだけです。彼らがルートアクセス権を持っているなら、彼らは彼らが望むことをほとんどすることができます。
Steve Morgan 電子メールアドレスを理解できなくても、多くの害を及ぼす可能性があるという良い点があります(SELECTアクセスしかなかった場合は軽減できます)
また、メールアドレスを保存する理由を知ることも重要です。 この回答 で少しやり過ぎたかもしれませんが、私のポイントは、アカウントのメールアドレスを本当に保存する必要があるのでしょうか?最も安全なデータは、存在しないデータです。
これは死んだトピックだと思いますが、この背後にあるArjanの論理に同意します。私が指摘したいことがいくつかあります:
誰かがソースコードを取得せずにデータベースからデータを取得できます(つまり、SQLインジェクション、サードパーティのデータベース)。これを念頭に置いて、キーによる暗号化の使用を検討することは合理的です。とはいえ、これはセキュリティの追加手段であり、セキュリティではありません...これは、電子メールをプレーンテキストよりもプライベートに保ちたい人のためのものです。 偶然にも、更新中に何かが見落とされたり、攻撃者がなんとか電子メールを取得したりします。
IMO: 電子メールの暗号化を計画している場合は、そのソルトハッシュも保存してください。次に、検証にハッシュを使用し、暗号化を絶えず使用して大量のデータ文字列を見つけるオーバーヘッドを節約できます。次に、メールを使用する必要があるときにメールを取得して復号化するための個別のプライベート関数を用意します。
ほとんどのセキュリティ要件と共通して、脅威のレベルを理解する必要があります。
電子メールアドレスが危険にさらされた場合、どのような損害が発生する可能性がありますか?
それが起こる可能性は何ですか?
電子メールアドレスが置き換えられた場合の被害は、公開された場合よりもはるかに大きくなる可能性があります。特に、たとえば、電子メールアドレスを使用して、安全なシステムへのパスワードのリセットを確認している場合。
パスワードをハッシュすると、パスワードが置き換えられたり公開されたりする可能性は大幅に減少しますが、他にどのようなコントロールを設定しているかによって異なります。
データベースの用途にもよると思います。
最大の問題は、暗号化キーをどこに保存するかです。ハッカーがあなたのDB以外のものを過剰に持っている場合、あなたのすべての努力はおそらく無駄になります。 (アプリケーションは、復号化および暗号化するためにその暗号化キーを必要とするため、最終的にハッカーは暗号化キーと使用される暗号化スキームを見つけることに注意してください)。
プロ:
短所:
暗号化と難読化を誤って混同しないでください。通常、スパムを防ぐためにメールを難読化します。多くのWebサイトには、クローラーが潜在的なスパムターゲットとして電子メールアドレスを解析するのを遅くするための「webmaster_at_mysite.com」があります。これはHTMLテンプレートで実行する必要があります。永続的なデータベースストレージでこれを実行する価値はありません。
送信中に秘密にしておく必要がない限り、暗号化は行いません。データはいつどこに送信されますか?
SQLステートメントはクライアントからサーバーに送信されます。それは同じ箱にあるのですか、それとも安全な接続を介してですか?
サーバーが危険にさらされていると、意図しない送信が発生します。これが心配な場合は、サーバーを保護しているはずです。内部の脅威だけでなく、外部の脅威もあります。すべてのユーザー(外部および内部)は適切に認証および承認されていますか?
バックアップ中に、バックアップメディアに意図的に送信します。これは、進行中に暗号化する安全なバックアップ戦略を使用して行われますか?
SQL ServerとOracleの両方(および他のDBも)は、データベースレベルでのデータの暗号化をサポートしています。何かを暗号化したい場合は、データベースサーバー側で暗号化できるデータへのアクセスを単純に抽象化せず、暗号化されたデータを使用するかどうか(この場合はSQLコマンドが異なります)をユーザーに選択させないでください。ユーザーが暗号化されたデータを使用したい場合は、データベースサーバーを構成でき、キー管理に関連するすべてのメンテナンス作業は、ユーザーではなくDBベンダーから作成された標準のDBAツールを使用して行われます。
データベース内のデータを暗号化することは価値があります。それは少し難しくはありませんが、正しい方法で暗号化するとはるかに難しくなるので、哲学を止めて機密データを暗号化します;)
私の回答のコピー データベースにユーザーの電子メールアドレスを保存するための最良かつ最も安全な方法は何ですか? 、検索のためだけに...
一般的に、私は他の人が努力する価値がないと言っていることに同意します。ただし、データベースにアクセスできる人なら誰でも、おそらくキーを取得できるとは思いません。これはSQLインジェクションには当てはまらないことは確かであり、何らかの理由で失われたり忘れられたりしたバックアップコピーには当てはまらない可能性があります。また、メールアドレスは個人情報であると感じているので、スパムは気にせず、アドレスが明らかになったときの個人的な影響については気にしません。
もちろん、SQLインジェクションが怖い場合は、そのようなインジェクションが禁止されていることを確認する必要があります。また、バックアップコピーは自分で暗号化する必要があります。
それでも、一部のオンラインコミュニティでは、メンバーは自分がメンバーであることを他の人に知られたくない場合があります(メンタルヘルスケア、経済的支援、医療および性的アドバイス、アダルトエンターテインメント、政治などに関連する場合など)。そのような場合、できるだけ少ない個人情報を保存し、必要なものを暗号化すること(データベースレベルの暗号化はSQLインジェクションを使用して詳細を表示することを妨げないことに注意してください)はそれほど悪い考えではないかもしれません。繰り返しますが、メールアドレスはそのような個人情報として扱ってください。
多くのサイトでは、上記はおそらく当てはまらないため、SQLインジェクションによるSELECT * FROM
の禁止に焦点を当て、訪問者がURLを変更して他人の個人プロファイルや注文情報にアクセスできないようにする必要があります。
誰かがそれらの電子メールアドレスを取得するという最悪のシナリオ、誰かがそれらを取得する可能性、および変更を実装するために必要な余分な労力/時間を実際に検討する必要があります。
@Roo
私はあなたの言っていることにいくらか同意しますが、誰かがデータを取得するのを少し難しくするためだけにデータを暗号化する価値はありませんか?
あなたの推論では、あなたの家に鍵や警報を置くことは、それらも簡単に危険にさらされる可能性があるので、役に立たないでしょう。
私の返信:
悪意のある人の手に渡りたくない機密データがある場合は、100%ばかげた証拠でなくても、ハッカーがそれを入手できるようにできる限り努力する必要があります。