1

私の現在のプロジェクトの 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 つです。セッション間でパスワードの「ハッシュ」を保存する必要があります (そのため、メモリ ストリームを使用することはできません)。

それは、私が気にする必要があるかどうか、そして私が行ったエンコーディング、ハッシュ、および暗号化が実際に十分かどうかということです。私が開発したピクチャパスワードシステムは、従来の「テキストベースのパスワードが何であるかを知っているので、今私はあなたのシステムにいる」という攻撃を阻止するための優れた基盤となっていますが、メモリから読み取るより技術的な攻撃については心配しています. .

4

1 に答える 1

5

SHA-512 を使用すると、ハッシュ値から初期コンテンツを取得することは不可能です (少なくとも 20 年間の計算能力と地球の電気エネルギーが必要です)。

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

あなたができることは、いわゆる「塩」を初期値に追加することです。このウィキペディアの記事を参照してください。

「salt」はコードに固定することも、パスワード内に保存することもできます。

あれは：

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

最後のアドバイス:

  • プレーンな初期テキストを DB またはファイルに保存しないでください。
  • 強力なパスワードの使用を強制します (辞書のおかげで簡単に解読できる「hellodave」ではありません)。
  • セキュリティ上の主な弱点は、椅子とキーボードの間です。
  • 偏執狂的である場合は、痛みの初期テキスト メモリを解放する前に明示的に (つまり、1 文字ごとに 1 文字ずつ) 上書きします (まだ RAM のどこかにある可能性があります)。
  • まず、よく知られているテクニックについて少し学びましょう。「チャレンジ」と「ナンス」を使用して、「リプレイ」または「メイン イン ザ ミドル」攻撃を回避することをお勧めします。
  • パスワード ハッシュを 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 など) および経験豊富な手法 (ソルト、チャレンジなど) に頼ったほうがよいでしょう。

認証方式のサンプルについては、クライアント サーバー フレームワークに RESTful 認証を実装する方法をご覧ください。確かに完璧ではありませんが、いくつかのベスト プラクティスを実装しようとしました。

于 2012-05-09T05:26:25.350 に答える