私は少し奇妙なジレンマに陥っています。説明しようと思いますので、ご容赦ください！
フォーム認証を使用しており、追加のユーザー情報を別のテーブルに保存しています（Forms Authから参照されるUserID、暗号化されたSSN、Salt値）。ユーザーがサイトに登録するとき、私はSSN、DOB、LNameに質問し、アカウントを作成する前にシステムと照合します。そのSSNにフォーム認証で関連付けられたアカウントがあるかどうかを確認したいと思います。SSNはソルト値で暗号化されているため、各行を確認せずにルックアップを実行することはできません。
SSNごとに1つのユーザーアカウントのみが必要です。ソルト値を使用すると、これが混乱します。
私の見方では、これを回避する唯一の方法は、SSNに一般的な暗号化アルゴリズムを使用することです。ユーザーが入力するときに、同じ暗号化アルゴリズムを適用して、ユーザー拡張プロパティテーブルに値が一致するかどうかを確認します。
これで十分安全ですか？
SSN値を暗号化（ハッシュではなく）する場合は、Natsoが指摘したのと同じテーブルにキーを格納することはお勧めできません。キーは保護するデータと一緒に保存されないため、これには危険が伴います。攻撃者がデータベースのダンプを取得できた場合、キーは一緒に保存されるため、暗号化されたコンテンツを復号化できます。
アプリケーションは、情報の暗号化/復号化に使用できる安全なキーストアからキーを取得する必要があります。このようにして、機密情報をデータベースに保存し続けて情報を保護し、別のメカニズム（通常はファイルシステムセキュリティ）を適用してキーストアを保護することができます。
もちろん、これは、データベースに安全な方法でデータを保存し、後で同じデータを回復することが要件であると想定しています。ただし、アルゴリズムを通過した後、データを回復可能にしない場合は、ハッシュの使用を検討する必要があります。
同じソルト値を使用するのではなく、他のユーザー情報に基づいてソルトを生成し、再構築できるようにします。したがって、ユーザーが適用するとソルトを再生成でき、予想されるハッシュを生成して、単一のクエリでジョブを完了することができます。
毎回同じ塩を使用してください。次に、暗号化された値を比較できます。