c# - パスワードをプログラムコードに安全に保存しますか？

Question

私のアプリケーションは、RijndaelManagedクラスを使用してデータを暗号化します。この暗号化の一部として、パスワードがロードされたSecureStringオブジェクトを使用します。このオブジェクトは、バイト配列に変換され、実行時にRajindaelManagedオブジェクトのキーにロードされます。

私が持っている質問は、このSecureStringのストレージです。ユーザーが入力したパスワードは実行時に入力でき、SecureStringオブジェクトに「安全に」ロードできますが、ユーザーが入力したパスワードが指定されていない場合は、デフォルトで何かを設定する必要があります。

したがって、最終的には、質問は次のようになります。

アプリケーションを実行するたびにSecureStringオブジェクトにロードする既知の文字列またはバイト配列が必要な場合、どうすればよいですか？「暗号化された」データは最終的に別のアプリケーションによって復号化されるため、ユーザーが入力したパスワードが指定されていない場合でも、あるアプリから別のアプリに移動するときにデータを暗号化する必要があります。これは、他のアプリがパスワードを適切に復号化できないため、デフォルトのパスワードをランダムにすることができないことを意味します。

私が考えている解決策の1つは、単一のパスフレーズのみを吐き出すdllを作成し、そのパスフレーズを使用して、実行時にいくつかの異なるハッシュ/再編成関数を実行してから、最終的にsecureStringオブジェクトにフィードすることです。これは十分に安全ですか？

わかりやすくするために編集*：暗号化されたデータは、マシン間でファイルを介して渡されます。常にパスワードが設定されているZipファイルと考えてください。ユーザーが直接何も入力しない場合は、デフォルトのファイルが想定されます。

Answer 1

実行可能ファイルにハードコードされた文字列を使用して対称的に暗号化しても意味がありません。それは誤った安心感を与えるだけです。このスキームを修正するハッシュの量はありません。

別のコンテキストでの同じポイントについては、このPidginFAQを参照してください。

アプリ間通信を暗号化する必要があると思う理由がわかりません。この通信がマシンに対してローカルである場合、暗号化、特にユーザー固有ではない暗号化の必要性はわかりません。これはDRMスキームですか？

編集：別のマシンに渡されている場合は、公開鍵をハードコーディングしてから、他のマシンに一致する秘密鍵を使用して復号化させることができます。

Answer 2

最初に最後の質問に取り組みましょう。

「これで十分安全ですか？」

答えられるのはあなただけです。ここでは、アプリケーションのコンテキストで「十分に安全」が何を意味するのかを誰も知りません。

10代の少女の日記をつけるためのアプリケーションを作っていますか？確かに、それは「十分に安全」です。

軍用グレードの安全なシステムの情報または認証を暗号化するアプリケーションを構築していますか？いいえ、近くもありません。

パスワードをソースコードに保存して実行可能にする場合は、1種類のセキュリティのみに依存できます。これは、隠すことによるセキュリティです。

パスワードをソースコードに保存できない、または保存しないという問題がある場合は、パスワードを別のdllに移動しても何も解決されません。問題を別のプロジェクトに移動しただけです。

しかし、私は何かについて疑問に思っています。あなたは「私は何かをデフォルトにしなければならない」と言います。それですか？安全なパスワード文字列のデフォルト値をソースコードに保存しようとしていますか？「THISISNOTAPASSWORD」はどうですか？

Answer 3

エリック・リッパートのあなたはそれで塩が欲しいですか？（元のブログ投稿）

また、彼の投稿を読んで、次のヒントで終わる仕事に適したツールを使用してください。

0. 可能であれば、そこに行かないでください。暗号化を正しく行うことは非常に困難であり、そもそも間違った解決策であることがよくあります。他の手法を使用して、セキュリティの問題を解決します。

1. 問題が信頼できないクライアントである場合は、クライアントを信頼する必要があるセキュリティソリューションを構築しないでください。

2. 既製の部品を使用できる場合は、そうしてください。

3. 既製の部品を使用できず、暗号システムを使用する必要がある場合は、完全に理解していない暗号システムを使用しないでください。

4. 完全に理解していない暗号システムを使用する必要がある場合は、少なくとも、解決するように設計されていない問題を解決するためにそれを使用しないでください。

5. 暗号システムを使用して木々をすり抜ける必要がある場合は、少なくとも、おそらく敵対的なクライアントが暗号化されたメッセージを選択することを許可しないでください。自分でトークンを選択してください。トークンにクライアントからの情報を含める必要がある場合は、何らかの方法でトークンをサニタイズします。ストレートASCIIテキストのみである必要があり、ランダムな空白を挿入するなど。

6. クライアントにトークンの選択を許可する必要がある場合は、トークン自体を暗号化しないでください。トークンの暗号的に安全なハッシュに署名します。攻撃者が目的のハッシュを生成するトークンを選択するのははるかに困難です。

7. 着信メッセージを保護する場合と同じキーペアを発信メッセージの暗号化に使用しないでください。実行する論理的に異なる操作ごとにキーペアを取得します。

8. 通信を双方向で暗号化します。

9. イブがあなたを攻撃していることを知ったら、少なくとも彼女のライセンスを取り消すことができるように、取り消しメカニズムを用意することを検討してください。（または、侵害されたことがわかっているライセンスを取り消すことができます。など）。

Answer 4

SQL接続文字列の保護に関するこの記事は、暗号化されたパスワードの保存にも同様に適用できます。暗号化されたパスワードの保存では、復号化のためにソルティングシードの暗号化をOSに処理させます。

Answer 5

おそらく、暗号化/復号化の代わりにPKIソリューションを使用する必要があるように思えます。暗号化されたデータを使用する必要がある別のアプリケーションがある場合は、そのアプリケーションのキーペアを用意し、暗号化を実行しているアプリに公開キーを与えることができます。そうすれば、データを安全に保つことができますが、最終的にはそれほど多くの保護を提供しない追加のコードを大量に導入することはありません。

簡単なグーグル検索で、.NetでのWindows証明書ストアの使用について説明しているこのCodeProjectの記事が見つかりました。