これは一見ひどいアイデアのように思えるかもしれませんが、これが私のシナリオです。ユーザー名認証を使用して複数の WCF エンドポイントを公開する Windows サービスがあります。カスタム オーセンティケーターは、ローカル データベースでユーザーの資格情報を検索するか (パスワードはソルト化された SHA-1 として格納されます)、別のサービスに WCF 要求を送信してパスワードを検証します。(ユーザー オブジェクトには、使用する認証ソースを示す、内部または外部の列挙型があります)。
ルックアップ + ハッシュ チェックを実行するか、WCF 呼び出しを行うと、サービスへのすべての要求に対して実行するのにコストがかかることがわかりました。そのため、ユーザー名とパスワードの情報をキャッシュしたいと考えています。キャッシュ内の各アイテムには有効期間があるため、たとえば、キャッシュ内のアイテムが 60 秒経過している場合、次の要求時にオーセンティケーターはキャッシュではなく元のソースに対して資格情報を検証し、それを更新します。
ローカル データベースの場合、ユーザー名と SHA1 のペアをディクショナリに格納するだけで済み、「内部」ユーザーからの要求ごとに、提供されたパスワードを再ハッシュして比較するだけで済みます。「外部」ユーザーの場合、プレーンテキストのパスワードのみをオーセンティケーターに送信するため、それをハッシュしてキャッシュの一部として保存するのは私次第です。これにより、データベース要求やリモート サービス呼び出しのオーバーヘッドが確実に節約されますが、それでも毎回ハッシュ操作を実行する必要があります。
問題のサービスは、物理的セキュリティとネットワーク セキュリティが良好な内部サーバーで実行されます。ハッシュ化されたバージョンを保存する代わりに、プレーンテキストのパスワードをキャッシュに保存することは許容される慣行ですか? その場合、私のリスクは、プロセスのメモリをダンプしてパスワードを取得する攻撃者のようです。そのリスクを許容できると考える場合、プレーンテキストのパスワードをメモリに保持しないようにする必要がある他の理由はありますか?
プレーンテキストのパスワードを使用することを選択した場合、SecureString によってリスクがある程度制限される可能性があると思います。SecureString を使用するのに苦労する価値はありますか (実装は非常に遠回りに思えます)。ハッシュ化されていないパスワードを永続的に保存することのリスクは十分に認識していますが、平文パスワードの揮発性ストレージに関するコンセンサスがどのように見えるかはわかりません。