PBKDF2をSRPベリファイア作成にフィードする
UDPのみを使用して通信する古いゲームがあり、エクスペリエンスポイントやランキングなどを容易にするために、ゲームにパスワード認証を追加したいと考えていました。そのために、既存のゲームプロトコルの拡張機能を使用してUDP経由で通信されるSRP-6aの実装を採用することにし、ゲームサーバーを介してトンネルされる、ゲームクライアント側で cocagne/csrp を使用することになりました。 、および mozilla/node-srp 認証サーバー側では、csrp互換のHAMKフォローアップ応答を生成するように若干変更されています。
これまでのところかなりうまくいきましたが、xを計算するプロセスでは、入力はベリファイアvに変換される前に一度だけハッシュされるようですので、 こちらを参照してください。 。私は、このライブラリ関数を私たちのニーズに合わせて変更し（かなり小さく、すでにツリー内にあるため）、PBKDF2に沿って何かを使用することを提案しました。しかし、私はこの性質のコードに触れることについて別の開発者から（理解できる）プッシュバックを受け取っています。 善意 など。
代わりに、おそらくユーザーのパスワード自体がPBKDF2ハッシュを受けてから、検証者作成およびユーザーチャレンジ関数にパスワードとして渡されることが提案されました。そうすれば、csrpライブラリ自体のコードを変更する必要がありません。これは有効なアプローチですか？または、これを行うと、別のクマのわなを待っているのですか？
それだけの価値があるので、完全なプロトコルドキュメントは here なので、他の種類のスナフスを作成している場合は、知っておくと便利です。
SRPのpasswordは、実際には（おそらく）低エントロピーの共有秘密です。これは、人間のユーザーが理解する「パスワード」、またはパスワードから決定論的に導き出されたものです。あなたの場合、はい、PBKDF2などのパスワードハッシュ関数を使用することは有効なアプローチです。次の警告があります。
PBKDF2は、bcryptやその他の優れたパスワードハッシュ関数と同様に、saltが必要です。塩はとても重要です。ソルトがなければ、攻撃者は攻撃を大幅に最適化する可能性があります。つまり、1人のユーザーに対してのみPBKDF2ステップの料金を支払う必要があります（複数のユーザーがクラックするために複数のハッシュを保存している場合）。ここでのポイントは、クライアントとサーバーが特定のユーザーに対して同じソルトを使用する必要があるため、クライアントは何らかの方法でknowそのソルトを使用する必要があるということです。ただし、saltは各ユーザーに固有である必要があり（ユーザーが自分のパスワードを変更するたびに変更される必要がある）、クライアントコードで単純にハードコードすることはできません。
したがって、ユーザーごとのソルトをサーバーに保存する必要がありますandを初期認証ステップとしてクライアントに伝達します。 SRPでは、クライアントは最初にユーザー名（[〜＃〜] i [〜＃〜]）とパスワードに依存しない値（[〜 ＃〜] a [〜＃〜]）。サーバーはユーザー固有のソルト（s）と別のメッセージ（[〜＃〜] b [〜＃〜]）で応答します。 PBKDF2に必要な追加ソルトをサーバーからクライアントへのメッセージでalsoを送信する必要があります。
または、replace SRPのハッシュステップをPBKDF2に変更することもできますが、これにはプロトコルの変更が含まれますand実装ライブラリ。これは、おそらく良いアイデアではありません。 add追加のPBKDF2ステップを実行する方が簡単で、全体的に安全です。
SRPで指定されたもの（プロトコル仕様ではsと呼ばれるもの）と同じソルトを再利用したくなります。これはここでは暗号的に安全に見えますが（2つのソルトの使用法は、それらの間のすべてのPBKDF2で「分離」されています）、この種のことは微妙な問題であることがわかっています。安全で慎重な方法です。
PBKDF2は、攻撃者の速度を低下させるために、多くの反復を採用しています。ただし、通常のユーザーの速度も低下するため、反復回数を希望するほど高くすることはできません。関連するコンピュータの負荷と計算能力、およびユーザーの忍耐力の限界を考慮して、許容できる限り高く設定する必要があります。
SRPとの統合の場合、他の [〜＃〜] pake [〜＃〜] プロトコルと同様に、パスワードハッシュの直接的なコストはクライアント側にあります。したがって、適切な反復回数はクライアントコンピュータによって異なります。複数のクライアントを使用している場合は、接続できるようになっていると思われる最も強力でないコンピュータに調整する必要があります。この点は、JavaScriptを使用するWebベースのクライアントにとって特に重要です。JavaScriptは生の計算では非常に扱いにくく、許容できる反復回数を大幅に制限するためです。あなたの場合、クライアントのコードはCライブラリを使用しているので、クライアント側の筋力を持つことができますが、「古いゲーム」で作業しているため、クライアントが「古いマシン」である可能性があることを考慮する必要があります。 "elder machine"。一部のi486コンピューターをまだ看護している変態者がいます。
PBKDF2の代わりにbcryptを使用することを検討してください。 bcryptはGPUを持つ攻撃者に対して 間違いなく強力 です。