loginID、password、logTimeなどのログイン情報を格納するテーブルがあります... 2つのストアドプロシージャを作成します。1つは暗号化用で、もう1つはパスワードを比較するためのものです。パスワードの暗号化と比較にはキーが必要です。鍵をどこに保管すればいいのか知りたいのですが。ストアドプロシージャまたはアプリケーションを入力すると、開発チームがそれを確認できるようになります。そして、キーを維持するためのベストプラクティスを知りたいです。ご意見をお聞かせください。
ありがとうございました。
認証資格情報を格納するためのさまざまなユース ケースがあり、それぞれに異なるソリューションが必要です。
クレデンシャルがシステムにログインするユーザーのものである場合、ベスト プラクティスはパスワードをまったく保存しないことです。代わりに、パスワードの一方向暗号化ハッシュを作成し、それを保存します。ユーザーがログインしようとすると、提供されたパスワードをハッシュし、結果を保存されたハッシュと比較します。ハッシュには、ユーザーのパスワードが変更されるたびに変更される「ソルト」が含まれている必要があります。これにより、誰かがシステムのハッシュ化されたパスワード ファイルを盗んだ場合に、ブルート フォース攻撃を適用してハッシュ コードを逆にすることが難しくなります。
クレデンシャルがサードパーティ システムにログインするユーザーのものである場合、システムにログインするためのユーザーのパスワードの異なる一方向ハッシュを生成し、保存されたユーザー クレデンシャルを暗号化/復号化するための対称暗号のキーとしてこれを使用できます。 . 繰り返しますが、核となる原則は、ユーザーの資格情報を解読するために必要な情報を保存しないことです。この場合、キーとして使用されるハッシュを保存しないでください。
クレデンシャルがシステム自体を他のシステムに対して認証するためのものである場合、通常の解決策は、キー ストアを使用し、ホスト オペレーティング システムによる保護と、ロック解除に使用されるキー フレーズに依存することです。（より良い解決策があれば、それについて聞いてみたいと思います!!）
ユーザーのパスワードを平文または暗号化して保存することはお勧めできません。誰かが侵入して盗む可能性が常にあるからです。パスワードが暗号化されている場合でも、復号化キーはどこかに保存する必要があります。断固たるハッカーなら、おそらくそれを見つけることができるでしょう。または、信頼できる管理者が、パスワードや復号化キーを明らかにするよう説得される可能性があります。パスワードではなくハッシュを保存することで、データベースやアプリケーションのキーストアが侵害された場合でも、保護の度合いが高まります。
式の 2 番目の部分は、多くのユーザーが多くのシステムで同じパスワードを使用することです。そのため、システムが侵害されてパスワードが明らかになった場合、他のシステムのユーザー アカウントが公開される可能性があります。
パスワードを暗号化しないようにハッシュする必要があります。そうすれば、キーはまったく必要ありません。
パスワードをどこに保存するかに関係なく、最終的にはパスワードを見つけることができます。したがって、他の開発者から隠したい場合は機能しません。