複数のスレッド用のArgon2idの構成

Question

argon2-jvm を使用して、=でArgon2idを使用しています= Java TCPサーバー。

そのargon2idインスタンスはスレッドセーフであるため、アプリの存続期間中は1つのインスタンスのみを作成し、必要に応じて（たとえば、新規登録やユーザーログインの場合）各リクエストハンドラーがそれを呼び出すようにします。

単一のargon2idインスタンスを微調整したので、からのアプローチを使用して、パスワードのハッシュと検証の両方が単一のスレッドで約1秒かかりますこの答え ：

使用できるスレッドの最大数を使用します（この場合、CPUの数x 2）。
使用できるメモリの最大量を使用します。
反復回数を調整して、ターゲットの最大時間（この場合は1秒）を超えないようにします。

ただし、argon2idインスタンスにアクセスするスレッド（TCPリクエスト）の数が増えると（たとえば、複数のユーザーが登録およびログインする場合）、実行時間も長くなります。

私たちの計画は現在、パスワードをハッシュして検証するのに約1秒かかるようにargon2idインスタンスを再構成することですが、1つのスレッドだけではなく、予想される同時登録の最大数とログ任意の時点でins（例：500 TCPリクエスト）。

私たちの懸念は、そうする場合、各リクエストが十分な処理を行わないため、ハッシュが十分に安全でない可能性があることです（たとえば、最大容量で約1秒かかるハッシュは、0.25秒しかかかりません。これが行われる唯一の要求です）。

最大容量のArgon2idを構成すると、個々のリクエストごとに安全な構成を下回るように感じます。これはどのように行われるはずですか？それとも、単一のスレッドでは1秒かかりますが、複数のスレッドではより長くかかる構成に固執する必要がありますか？

UPDATE：また、Crypto subredditに意見を求めましたここ。

mentallurg · Accepted Answer

完璧な解決策はありません。セキュリティ、価格、ユーザーエクスペリエンスの間には、常にトレードオフがあります。より高いセキュリティと許容可能な応答時間の両方を実現したい場合は、より多くのハードウェアリソース（より高い価格）の使用を検討してください。

まずリスクを推定する実際に必要なセキュリティレベルを決定します。脅威とは正確には何ですか？単一のパスワードの総当たりが成功した場合、攻撃者はどのような利点を得ることができますか？攻撃者が単一のパスワードをブルートフォースで攻撃するのに必要な費用を教えてください。考えられるメリットとコストは相応ですか？それはハッカーにとってまったく意味がありますか？特定のレベルのセキュリティを提供するために、あなたとあなたのユーザーにはどのようなコストがかかりますか？例えば。サーバー/コンテナーあたりのリクエスト数を500から100に減らし（より多くのハッシュ反復を可能にするため）、サーバー/コンテナーの数を5倍に増やすと、価格5倍になりますか？

また、2つの基本的な使用例を区別する必要があります。

1人のユーザーがいます。たとえば、ラップトップのユーザーは、ハッシュ（派生パスワード）をパスワードマネージャーのマスターパスワードとして使用したり、ドライブを暗号化/復号化したりします。次に、単一のハッシュができるだけ多くのリソースを使用することは理にかなっています。
たとえば一部のWebアプリケーションでは、複数の同時リクエストがあります。一部のリクエストで必要なリソースが多すぎる場合、他のリクエスト（パスワードを使用しない通常のリクエスト）ではパフォーマンスが低下します。

スレッド数：このパラメーターの主な目的は、メモリバスをできるだけ多くロードすることです。しかし、通常のCPUにはメモリチャネルが2つしかなく、多くのグラフィックカードには6または8があります。したがって、yourサーバーを使い果たしても、リソースを使い果たしません攻撃者。つまり、セキュリティが向上するわけではありません。そのため、1つのスレッドを使用することをお勧めします。

Memory：アプリケーションは、アクセス許可の評価、ビジネスロジックの計算、特定の複雑な条件のデータの検索、レポートの作成など、ハッシュ以外の多くのロジックを実行している可能性があります。主要な機能のパフォーマンスを許容範囲内に保つために、ハッシュはどのくらいのメモリを使用できますか？分析後かもしれませんが、使用可能なメモリの5％以下のハッシュに使用できると結論付けます。モデル化して計算するだけです。

反復回数：次に、反復回数を調整して、許容可能な応答時間を取得します。

次に、実際のユーザーがいる実際の環境で仮定を確認します。パフォーマンスが十分でないことがわかった場合でも、チューニングすることができます。古いハッシュに対するパスワード検証が成功した後、新しい（最適化された）パラメーターを使用してパスワードを再ハッシュし、データベースに保存できます。