文字列暗号化の問題

Question

私の現在のプロジェクトの1つでは、私はシングルユーザー認証システムを利用しています。同じWindowsアカウントで複数のユーザーがこの作業を行う予定がないため、私は「シングルユーザー」と言います（これは単に私が探しているものではないからです）。

ユーザーがアプリケーションを起動すると、認証画面が表示されます。この認証画面は、画像（すなわち、画像内の3つの特定の点をクリックする）、ユーザ名（標準編集ボックス）、および画像選択肢（使用する画像を選択できるドロップダウンメニュー）を使用する。イメージの選択、ユーザー名、およびイメージ上でクリックしたポイントは、パスワードを設定するときにユーザーが指定したものとすべて一致する必要があります。

すべて3の結果は、次いでSoap.EncdDecd.EncodeString方式で符号化された文字列に結合されています。これはSHA-512を使用してハッシュされます。最後に、DESを使用して暗号化されています。この値は、パスワードを設定したときに作成された値と比較されます。一致すると、アクセス権が与えられます。そうでない場合、アクセスは拒否されます。私は、SHA512の値をアプリケーションの他のポイントで使用する予定です（メインアプリケーション内のさまざまなモジュールで自分自身を認証するための「マスターパスワード」など）。一例では

は、最初の文字列の長さは29文字であり、SOAPエンコードされた文字列は、約40文字であり、SHA-512の文字列は、128文字であり、DES値は344個の文字です。私は大規模な文字列で作業していないので、実際には本当に速いです。 SOAPはセキュリティの手段としてではなく、非常に基本的な難読化として使用されていました。

私の懸念は、最初の部分（プレーンストリングとSOAP）が弱点になる可能性があることです。基本的な文字列は、単に入力してアクセス権を与えることはできませんが、アプリケーションにアクセスする可能性のあるユーザー名と画像の選択とともに「画像のクリック座標」を与えます。 SOAP文字列は簡単に解読できます。ストレートメモリからリッピングされた値を試してみて、避けるために、認証のこの最初の部分を強化するための最良の方法だろう何

？私は、潜在的な悪用者や攻撃者がこのような方法で値を読み取ることについても気にする必要がありますか？直接この同じトピックに関連する追加の質問として

。ユーザーは、初期設定時に作成したパスワードのハッシュを格納するための最良の方法だろう何

？

私はまだ、よりエレガントな何かを思いついていないので、私はTIniFile.SectionExistsメソッドで現在実行しています。これは私の知識が欠けている1つの領域です。私はセッションの間にパスワード "ハッシュ"を格納する必要があります（メモリストリームを使用することはオプションではありません）が、セキュリティは十分であることを確認する必要があります。

---

エンコード、ハッシング、暗号化が実際には十分であるかどうかは、私が心配すべきかどうかという点では本当に重要です。私が開発した画像パスワードシステムは、すでに伝統的なものを停止するための素晴らしい基盤です"あなたのテキストベースのパスワードは今私があなたのシステムにいることを知っています"攻撃ですが、メモリから。 SHA-512を使用し

Answer 1

は、それが不可能なハッシュ値から初期コンテンツを取得する（少なくとも計算パワー、及び土の電気エネルギーの20年前）。

私は、DESの使用は必須ではなく、複雑さを増すとも思っています。もちろん、このような低速プロセスを使用することで、ブルートフォース攻撃や辞書ベースの攻撃を難しくすることができます（それぞれの試行が遅くなるため）。より一般的なのは、DESを使用するのではなく、SHA-512を何度か（例えば1000回）呼び出すことです。この場合、スピードはあなたの敵になる可能性があります：迅速なプロセスは攻撃しやすくなります。

あなたがすることがあるのは、初期値にいわゆる「塩」を加えることです。 this Wikipedia articleを参照してください。

「塩」はコード内で修正することも、パスワードに保存することもできます。

Hash := SHA512(Salt+Coordinates+UserName+Password); 

最終アドバイス：ある

• DBやファイルにプレーン初期テキストを保管しないでください。
• 強力なパスワードを強制的に使用します（「hellodave」ではなく、辞書のおかげで簡単に破損する可能性があります）。
• 主なセキュリティの弱点は、椅子とキーボードの間です。
• あなたが妄想である場合、それを解放する前に痛みの最初のテキストメモリを明示的に上書きします（RAMのどこかにまだ残っている可能性があります）。
• 最初によく知られている手法について少し学びます。「challenge」と「nonce」をよく使用して、「replay」または「main in the middle」という攻撃を避けるべきです。
• 強力な認証方式（チャレンジレスポンスなど）に注意し、サーバーアクセスを保護する場合は、パスワードハッシュをDBまたはINIファイルに保存することは安全です。例えば

、ここにあなたの記憶を「きれい」に（それははるかに複雑これ以上かもしれない）方法です：

Content := Salt+Coordinates+UserName+Password; 
for i := 1 to length(Coordinates) do 
    Coordinates[i] := ' '; 
for i := 1 to length(UserName) do 
    UserName[i] := ' '; 
for i := 1 to length(Password) do 
    Password[i] := ' '; 
Hash := SHA512(Content); 
for i := 1 to length(Content) do 
    Content[i] := ' '; 
for i := 1 to 1000 do  
    Hash := SHA512(Hash); 

それがセキュリティを扱う場合は、車輪の再発明をしようとしないでくださいそれは困難な問題であり、数学的に証明された（SHA-512のような）経験豊富なテクニック（塩、挑戦など）にもっと頼る方がよいでしょう。

認証方式のサンプルについては、how we implemented RESTful authentication for our Client-Server frameworkを参照してください。確かに完璧ではありませんが、いくつかのベストプラクティスを実装しようとしました。