したがって、めったに使用されないように見えるこのクラスがあります：SecureString。少なくとも2.0から出回っていて、いくつかのSOの質問がありますが、私は自分自身の特定の質問をしたいと思いました。
LoginFormがあります。ユーザー名と（マスクされた）パスワードフィールドを含む単純なWinFormsダイアログ。ユーザーが両方を入力して[ログイン]をクリックすると、情報はキーストレッチのレイヤーを実行する挿入された認証クラスに渡され、検証のためにストレッチされたキーの半分をハッシュし、残りの半分は暗号化されたユーザーの対称キーですアカウントデータ。これがすべて完了すると、loginFormが閉じられ、オーセンティケータークラスが破棄され、システムはメインフォームのロードに進みます。かなり標準的なもので、標準のパスワードと比較のハッシュよりも少し複雑かもしれませんが、私の場合、単純なハッシュパスワードは、ユーザーデータをプレーンテキストで保存することで無効になります。これは、そのデータに3分の1の資格情報が含まれているためです。パーティーシステム（そして私たちは皆、人々がパスワードを再利用する方法を知っています）。
これが最初の質問です。SecureStringを使用して、テキストボックスのTextプロパティを介して通常のSystem.Stringとして公開せずに、Passwordテキストボックスからパスワードを取得するにはどうすればよいですか？CLRクラスによってラップされているテキストボックスのアンマネージGDIウィンドウにアクセスし、Marshalクラスを使用してテキストデータをプルする方法があると思います。方法がわからず、良い情報が見つからないようです。
これが2番目の質問です。SecureStringとしてパスワードを取得したら、System.Security.Crypto名前空間からハッシュプロバイダーにパスワードを渡すにはどうすればよいですか？私の推測では、Marshal.SecureStringToBSTR（）を使用してから、返されたIntPtrからバイト配列に戻るMarshal.Copy（）を使用します。次に、Marshal.ZeroBSTR（）を呼び出してアンマネージメモリをクリーンアップし、ハッシュを取得したらArray.Clear（）を使用してマネージ配列をゼロにすることができます。メモリの管理されたコピーの存続期間を完全に制御できるよりクリーンな方法がある場合は、教えてください。
3番目の質問; これは本当に必要なことですか、それともマネージドメモリ環境でのSystem.Stringの固有の不安定さは少し誇張されていますか？暗号化されているかどうかにかかわらず、パスワードの保存に使用されるものはすべて範囲外であり、OSがアプリを仮想メモリにスワップすることを検討するずっと前にガベージコレクターに向かう必要があります（パスワードをスワップファイルからスニッフィングできるようにするコンピュータのハードシャットダウン）。コールドブート攻撃は理論的な可能性ですが、実際、これはどのくらい一般的ですか？より大きな懸念は、現在復号化されているユーザーデータです。これは、アプリケーションの存続期間全体にわたってユーザーの一部として存在します（したがって、いくつかの基本的な使用法を除いて、SecureStringsを使用するための主要な候補となります）。