パスワード情報をデータベースに保存する最良の方法について読んでいますが、ほとんどの例では、実際のパスワードをデータベースに保存するのではなく、ハッシュ値とソルト値を保存する必要があると述べています。Webアプリケーションでは、ユーザーを認証するコードはサーバー側にあるため、ユーザー名とパスワードをネットワーク経由で送信し、サーバーでソルト値を読み取り、受け取ったパスワードをソルトでハッシュして比較しますdb に保存されたハッシュ値を使用します。
アプリケーションがクライアント上にあり、アプリケーションが何らかのサービス (ローカル ネットワーク) ではなくデータベースに直接接続している場合はどうなりますか? これは、ハッシュ クラスがクライアント上で公開されることを意味し、クライアント上のデータベースからハッシュ値とソルト値を読み取る必要があります。これにより、誰でも数行のコードを作成し、クライアント上のすべてのユーザー情報を取得できるようになります。
このようなシナリオでは、セキュリティ/認証はどのように処理されますか?
Windows 認証
アプリケーションが Windows ドメイン内で実行されている場合は、認証された Windows ユーザー情報を使用できます。次に、データベースにユーザー名/パスワードを保存する必要はありません。ユーザー テーブルでユーザーを識別するために Windows SID を格納するだけで済みます。次に、アプリケーションは、現在のユーザーがデータベースの User テーブルに存在することを確認するだけで済みます。存在しない場合、アプリケーションは実行に失敗します。
WindowsIdentity.GetCurrent() (MSDN)を使用して現在のユーザー情報を取得でき、User プロパティを使用して SecurityIdentifier にアクセスできます。C# でユーザー名を SID 文字列に変換するという質問は、それをデータベースに格納できる文字列に変換する方法を示します。各 Windows ユーザーには一意の SID があるため、セキュリティ情報を簡単に検索できます。
この方法でセキュリティを強化するには、SQL 接続に統合セキュリティを使用し、クエリとテーブルへのアクセスをロックダウンして、特定のユーザーグループのみが管理アクションを実行してユーザーを追加し、通常のユーザーのみが管理アクションを実行できるようにすることをお勧めします。関連するテーブルに対して読み取りおよびデータの挿入/更新ステートメントを実行します。
編集：
Windows 認証は機能しないため、ストアド プロシージャで SQL にハッシュを実行させることができます。HASHBYTESを使用するユーザー名/パスワードをストアド プロシージャに渡し、SQL で検証を実行して、エンド ユーザーがロジックを見ることができないようにすることができます。ストアド プロシージャでは、Salt 値をテーブルから取得するか、コーディングすることができます。たとえば、ユーザー名、パスワード、およびユーザー情報テーブルからの別の値を使用して、ハッシュされる値を作成します。これにより、パスワードが同じであっても、異なるユーザーが同じハッシュを持つことを防ぎます。また、SHA512 を使用してハッシュを生成します。次に、ユーザーが SQL に接続できないように SQL アクセスをロックダウンし、ストアド プロシージャを右クリック --> [変更] を実行してソースを表示する必要があります。これはおそらくあなたのケースに最適です。