機密情報を暗号化する必要がある Web アプリケーションを開発しています。私の計画は、秘密鍵がユーザーのパスワードのハッシュによって暗号化される AES-256 を使用することです。認証のためにパスワードのハッシュを保存する必要がありますが、明らかに秘密鍵の暗号化には使用できません。私の現在の考えは、bcrypt を使用して秘密鍵の暗号化に使用する鍵を生成することです。認証については、単純に bcrypt を使用してパスワードをハッシュし、次に bcrypt を使用してそのハッシュを再度ハッシュし、そのハッシュをデータベースに保存することを考えました。それは一方向であるため、保存されたハッシュを使用して秘密鍵を復号化する方法はありませんか? これを行うと、私が見逃している可能性のある明らかなセキュリティ上の問題はありますか?
もう 1 つの考えは、bcrypt ハッシュを使用して秘密鍵を暗号化し、SHA-2 ハッシュを認証目的で保存するなど、2 つの異なる暗号化アルゴリズムを使用することでした。
ご協力いただきありがとうございます。
ハッシュを使用して AES パスワードを暗号化しないでください。ソルト ハッシュは、認証にのみ使用する必要があります。ユーザーがログインすると、パスワードが表示されます。このパスワードを使用して AES キーを暗号化 (初回) および復号化 (後で) した後、パスワードを忘れてしまいます。
この状況ではPBKDF2を使用することをお勧めします。2 つの異なるソルトを使用できます。1 つは対称キーを導出し、もう 1 つは保存するパスワード ハッシュを導出します。ソルトには、2 つの異なるユース ケースを区別する決定論的な部分と、ランダムな部分が含まれている必要があります。このコメント:
それ以外の場合、ソルトには、少なくとも 8 オクテット長のランダムな部分に加えて、異なる操作と異なるキーの長さを明示的に区別するデータが含まれている必要があり、このデータはソルトを受信する側でチェックまたは再生成する必要があります。たとえば、ソルトには、派生キーの目的を指定する追加の非ランダム オクテットを含めることができます。または、暗号化または認証技術、およびパスワードから派生したさまざまなキー間のシーケンス番号など、派生キーに関する詳細情報を指定する構造のエンコードである可能性があります。追加データの特定の形式は、アプリケーションに任されています。
コメントで言及されているように、一般的なパスワードのエントロピーが貧弱であるため、プレーンでソルト化された SHA-2 ではおそらく十分ではありません。
提案: 2 つの異なる塩を使用します。ユーザーがパスワードを入力すると、パスワードをランダムなソルトと連結し、パスワード認識ルーチンのためにハッシュします。別のソルトを使用して、AES 暗号化キー用に再度ハッシュします。必要なセキュリティに応じて、ハッシュを拡張することもできます。
事実上、次のものがあります。
storedPasswordCheck = SHA256(password + salt1);
AESkey = SHA256(password + salt2);
もちろん、AES キーは保存されませんが、必要に応じてユーザーのパスワードから再生成されます。2 つの個別のソルトが必要です。それぞれのユーザーごとに少なくとも 128 ビットが保存されているのが最適です。