DBがリークした場合に使用するSRPベリファイアを保護するための推奨ソリューションはありますか？
SRPプロトコルを使用したい新しいウェブサイトに取り組んでいます。したがって、ソルトとベリファイアはサーバーに送信され、理論的にはサーバーはそれらをデータベースに保存します。 DBがリークされた場合、攻撃者は確実にユーザーパスワードをブルートフォースし、検証者/ソルトで確認する可能性があります（Argon2のような優れたKDFを使用している場合でも）。これを防ぎたいのですが、推奨される解決策はありますか？
私の現在の解決策：
RESTfulサービスの開始時に、マスターパスワードが手動で入力され、Argon2で複数回ハッシュされます（各パスワードのバイトをXORして、最大255の数値を取得します）。このマスターパスワードハッシュは、機密情報をDB（salt、SRP verifier）に保存する前に、AES-GCMで暗号化するために使用されます。
この方法では、ソースコードやハードドライブを使用していても、DBが漏洩した場合、攻撃者はSRPベリファイアを悪用することはできません。私が考えている唯一の攻撃は、ルートキットをインストールし、メモリをダンプしてマスターパスワードを見つけることです。
パスワードハッシュのデータベースと同様に、辞書ベースの攻撃を防ぐための従来のアプローチは、パスワードからのコンピューティングハッシュ（またはこの場合は検証者）に十分なコストをかけることです。
SRPの場合、これを行うための明白な方法は、十分に大きいグループを選択することです。 （いずれの場合も、RSAまたはDHの場合と同様に、暗号解読に抵抗するのに十分な大きさである必要があります。）
明らかに、グループのサイズを大きくすると、クライアントとサーバーの両方の速度も低下します。
別の可能性は、RFC 2945のセクション3.2で提案されているように、SHA-1を別のハッシュ関数に置き換えることです。SRP-SHA1で使用されるソルトSHA-1構造は、別のメッセージダイジェスト、HMAC、またはパスワードハッシュ関数に置き換えることができます。 。
私の意見では、SHA-1の代わりにArgon2、BCrypt、PBKDF2などの優れたパスワードハッシュ関数を使用することは理にかなっています。これを行うと、サーバーのパフォーマンスに影響を与えることなく、辞書攻撃のコストが増加します。 （ただし、クライアントのパフォーマンスは影響を受けます。）一方、これは暗号解読に対する耐性を向上させません。
SRPは、攻撃者がサーバーのメモリにアクセスできることを前提とした脅威モデルでパスワードを保護するように設計されています。したがって、SRPは、攻撃者がマスターパスワードにアクセスできる状況で安全になるように設計されています。
上記のことは、SRPが実際にパスワードマネージャーと競合することも意味します。後者は、より広く展開されているソリューションです。ユーザーがサイトごとに一意のパスワードを持つパスワードマネージャーを既に使用している場合、SRPはほとんど役に立ちません。
保存されたベリファイアの暗号化は、基本的にパスワードデータベースの「ペッパー」と同じです。これにより、非常に複雑になります。これによりシステムのセキュリティが向上するかどうかは明らかではありません。
これは、攻撃者がデータベースにアクセスできるがサーバーにはアクセスできないと想定する場合にのみ意味があります（SRPの使用は、攻撃者がサーバーにアクセスできると想定する場合にのみ意味があります）、マスターパスワードのエントロピーが良好で、暗号化コードが適切である書き込まれます（IVは適切に生成されます...）
Argons2の使用に関しては、パラメーターを固定する必要があります。できるだけ多くのメモリと処理能力を使用してください。パラメータをパスワードに依存させないでください。