私はPHP MySQLベースのWebサイトを構築し、暗号化されたユーザーの詳細を保存し、その他すべてのフィールドをプレーンテキストにすることを経験しています。最新のプロジェクトでは、機密データをデータベースに保存する必要があります。
ユーザーが自分のエントリにアクセスしてプレーンテキストの結果を表示できるシステムをセットアップしたいのですが、他のユーザーにアクセスできたとしても、それらは暗号化された、理解できない文字列になります。
私はこれを達成する方法を考えていますが、おそらくそれは最適ではないか、すでにより効率的な方法でこれを行うためのツールが存在します。
1.)ユーザー名をプレーンテキストとして保存し、パスワードをsha1()以上のハッシュアルゴリズムとランダムソルトなどでハッシュ化します。
2.)ユーザーのパスワード(ハッシュされたものではなく、入力したもの)を使用して、そのユーザー名とパスワードに固有のキーを定義し、セッション変数として格納します。キーはユーザーの頭を除いてどこにも保存されないため(ユーザーがプレーンテキストのパスワードを知っているという形で)、ユーザーの入力に応じて、ユーザー名やソルト、ハッシュなどと混合することでキーに変換されますログインする)これは良い解決策ですよね?
3.)そのキーでそのユーザーのすべてのデータを暗号化または復号化します。
私の意見では、誰かがデータベースにアクセスし、プレーンテキストのユーザー名と暗号化されたパスワードのリストを見たとしても、どこにも保存されていないため、特定のキーを見つけることができませんでした。したがって、アクセスが取得されたとしても、機密データベースフィールドの内容を解読することはできませんでした。もちろん、私はとにかく彼らがデータベースにアクセスするのを止める方法で構築していますが、万能の努力として、これは良い一連のステップのように思えます。
専門家はこれについてコメントして、いくつかのアドバイスを提供できますか?どうもありがとう。
私はこれをprogrammers.SEフォーラムに投稿しました、そして彼らは私にこれが質問にとってより良い場所であるとアドバイスしました。より具体的には、私がこれを自分で行うべきではない理由。もしそうなら、どのような選択肢がありますか?
あなたが話しているのは派生キーです。ここで説明する手法は、高セキュリティシステムで頻繁に使用されますが、派生したデータキーの暗号化を使用することをお勧めします。これにより、データキーを複数の派生キーと共に格納でき、派生キーの使用が制限されます。これにより、データの共有、キーリング、アカウントの復元が可能になります。また、派生キー自体はパスワードと同じ強さしかないため、ソルティングおよび低速キー派生関数を引き続き使用して、すべてのユーザーのパスワードに対して一度にパスワード派生キーを形成できないようにする必要があります。
派生キーは、真にランダムなキーよりも弱い傾向があるため、可能な限り最小量のキーを暗号化する必要があります。ユーザーのデータキーのみを暗号化すると、ユーザーのデータキーを復号化してセッションに格納できます。その真にランダムなキーは、ユーザーのデータの暗号化と復号化に使用できます。
さらに機能が強化されたのは、レコードにキーを関連付け、次にユーザーキーを使用してそのレコードキーを暗号化し、ユーザーにアクセスを許可することです。ここで非対称暗号化を使用する場合、ユーザーは、共有したいユーザーの公開鍵でレコードキーを暗号化し、それを他のユーザーのキーリングに追加することで、レコードレベルのアクセス権を別のユーザーに付与することができます。
同様に、アカウント回復の場合、ユーザーキーは公開回復キーで暗号化できます。秘密鍵は、オフラインにしておくか、(類似した派生鍵保護を使用して)管理ユーザーに関連付けて、アカウントを復元する必要がある場合にのみカスタマーサービスで使用できます。
これを使用してキー(…)を定義します。キーはセッション変数として保存されます。キーはユーザーの頭以外には保存されないため(…)
一時的ではありますが、キーisはサーバーに保存されます(たとえば、基本的なセッションハンドラーは/ tmp内のファイルを使用しますが、memcachedのメモリダンプは、有効期限が切れた後でもキーを明らかにする可能性があります)。サーバーがどのようにセッションを維持しているかを確認して、それらのキーが(簡単に)渡されないことを確認してください。
ランダムなCookie値を使用して、セッションに保存されたその値を再暗号化することができます。またはまったく保存しないでください。
クライアント側ですべての暗号化を実行する場合のボーナス(JavaScriptを使用)。その後、サーバーneverはデータを参照するため、攻撃者がデータを侵害することはできません。
(攻撃者は依然として正当なコードを悪意のあるコードに置き換え、ユーザーがサイトにアクセスしてデータを盗むのを待つ可能性があることに注意してください。これは以前から可能でした)