7

ゴール：

カスタムWebアプリ（ショアホスティング環境ではPHP / MySQL）でユーザーが質問を作成し、他のユーザーから情報を収集できるようにし、収集したデータを保護したいと思います。

バックグラウンド：

すべてのユーザーが回答するデフォルトの質問は一般的であるため、個人を特定できる情報（PII）として解釈できないため、保護する責任が制限されますが、独自の質問を作成するユーザーはPIIを要求する可能性が高く、これが責任になります。

私がやりたいのは、ホスティングアカウントまたはデータベースのいずれか（または両方！）が侵害された場合に、かなりの量の作業がなければPIIを回復できないように、そしてそれでも、理論的には、ごく一部が回復可能です。

提案された解決策：

MySQLの組み込みAES_ENCRYPT()/AES_DECRYPT()関数を使用してPIIテーブルを暗号化すると仮定すると、パスフレーズをホスティングアカウントに保存する必要があるため、ホスティングアカウントが侵害された場合でも、データを簡単に読み取ることができます。

ユーザーのパスワードは十分に保護されている（ソルトでハッシュ化されている）ため、認証中にプレーンテキストのパスワードをキャプチャして暗号化し、ユーザーがログアウトするまでPHPセッションに保存することを考えています。

公開鍵と秘密鍵の組み合わせがユーザーごとに作成され、秘密鍵はユーザーのパスワード+ソルトでパスワード保護されます。

次に、そのユーザーのカスタム質問に基づくPIIデータがDBに追加されると、ユーザーの公開鍵を使用して、アプリを通じて収集したPIIが暗号化されます。データが読み取られると（ユーザーがログインしている場合のみ）、データはユーザーの秘密鍵（パスワードとソルトでロック解除されます）で暗号化されません。

私が見る利点は次のとおりです。

  1. サーバーが完全に侵害された最悪のシナリオでは、暗号化キーを見つけるためにアプリコードが読み取られ、ユーザーのパスワードを見つけるためにPHPセッションファイルが復号化され、次にそのユーザーに関連付けられたPIIテーブルのエントリが復号化され、質問からPIIのみが収集されます。現在ログインしているユーザーの数を回復できます。ログインしていないユーザーは安全です。
  2. DBAなどでさえPIIを読み取ることができません。

私が見る欠点は次のとおりです。

  1. ユーザーパスワードは、ログインしている間、回復可能な形式で保存されます。
  2. パスワードを忘れたユーザーは、データにアクセスできなくなります。
  3. 暗号化により、データの各比較的小さなビットがDB内ではるかに多くのスペースを占有します。

私の質問：これを行うためのより良い方法はありますか？

4

2 に答える 2

7

セキュリティの観点から、この設計には多くの問題があります。まず第一に、パスワードは決して暗号化してはなりません。これはCWE-257によって特定された脆弱性です。

さらに多くのMySQLAES_ENCRYPT()は、複数の理由で完全なゴミです。これはEBCモードを使用しており、これががらくたである理由の良い例です。

元の画像：

ここに画像の説明を入力してください

EBCモード（mysqlがAES_ENCRYPT()使用するもの）：

ここに画像の説明を入力してください

しかし、攻撃者が侵害したデータベースがクエリログAES_ENCRYPT()を有効にすることで敗北しようとしている場合。

暗号化にユーザーのパスワードを使用することは避けてください。ノンスを使用する必要があります。パスワードを使用する場合は、必ずString2Key関数を使用してください。また、ランダムivでCBCまたはCMACモードを使用する必要があります。非対称暗号化がどのように役立つのか、私にはよくわかりません。非対称暗号化は非常に遅く、メモリを大量に消費します。暗号文メッセージを比較できるため、攻撃者がメッセージを制御すると、保護するデータの安全性が低下します。これがランダムIVが重要である理由であり、非対称の世界ではこのレベルの保護はありません。

キー生成は次のようになります。 $key=string2key($base_nonce.$salt.$user_password)

string2key関数の出力がキースペースと同じサイズであることを確認してください。したがって、aes128には128ビットキーが必要です。各パスワードには独自のが必要$saltであり、$baseはテキストファイルに保存されている暗号化ナンスです。（攻撃者は、キーを解読する前にこのファイルを読み取る必要があります。この値が128ビットのように大きい場合は、その重要なポイントです。）各メッセージには独自のメッセージが必要$ivであり、この値も暗号ナンス（ソルトと同様）である必要があります。 ）。$salt、、$ivおよび$base_nonceからを生成し/dev/urandomます。IVは、暗号文とともにデータベースの列にプレーンテキストで保存できます。

法的な観点から、安全な暗号化システムを構築したとしても、内部脅威の問題があり、サーバーが完全に侵害された場合でも、すべてのデータが侵害されます。これは実際にはエンジニアリング上の問題ではありません。

法的脅威に対する最善の防御策は、熟練した弁護士によって作成された強力な契約条件です。

于 2011-09-01T15:55:13.370 に答える
0

私が持っている1つの懸念は次のとおりです。「ログインしていないユーザーは安全だ」という部分は楽観的すぎます。秘密鍵をユーザーのパスワードで保護することにより、さまざまなパスワードブルートフォース攻撃にさらされる可能性があります。現在のセッションだけでなく、すべてのセッションに。効果的な方法の1つは、たとえば、上位100の一般的なパスワードを単純に列挙し、すべてのユーザーに対して試してみることです。攻撃者はいくつかの鍵を発見することになります。（攻撃者が見ることができるユーザーレコードとともにユーザーごとのランダムソルトを保存しているか、攻撃者が侵害を通じて取得できた秘密のソルトを持っていると想定しています。）

于 2011-09-01T13:37:20.033 に答える