SRPのオフラインクラッキングを困難にするためにどのような手順を実行できますか？
ブリザードハックの余波で、SRPのオフラインクラッキングをより困難にするためにどのような手順を実行できますか？
私の質問は、データベースがすでになくなっており、SRPを多かれ少なかれ適切に実装していることを前提としています。
SRPでは、サーバーはパスワードから派生したトークンを保存します。これは、オフライン辞書攻撃でパスワードを推測するために使用できます（攻撃者は、一致するものが見つかるまで潜在的なパスワードを試みます）。これはSRPの欠陥ではありません。サーバーには必要に応じて、使用されている認証プロトコルに関係なく、同様のパスワード派生データが含まれています。 SRPの魔法は、プロトコルの他の場所では、このようなパスワードから派生したデータが得られないことです（攻撃者がサーバーになりすまそうとしても）。しかし、サーバー自体が危険にさらされている場合（その秘密はすべて攻撃者に知られている）、オフライン辞書攻撃が可能です。
このトークンの強化には、通常のツール、つまりソルトと反復が含まれます（ bcrypt を参照）。実際には、これはbcryptの出力がSRPで「パスワード」として使用されることを意味します。
2つのオプションがあります。 SRPはユーザーのパスワードのハッシュを計算し、それをべき乗して、結果を保存します。オプション1：そのハッシュを「スローハッシュ」に置き換えることができます-PBKDF2をお勧めします。オプション2：PBKDF2でパスワードを事前にハッシュしてから、以前のように結果を使用できます。 SRPのハッシュ関数Hとしてkey-derivation-functionを使用できますか？ ;詳細な数学については、私の回答をご覧ください。これらのオプションのいずれかが問題を解決します。
関連：
ベリファイアをdbで暗号化できること、そして暗号化すべきであることに人々が気付いていないことに驚いています。通常、大企業では、データベースは分離されたインフラストラクチャです。データベースサーバーのバックアップ方法も、通常、アプリケーションサーバーやWebインフラストラクチャのホストレベルのバックアップとは意図的に異なります。 Dbバックアップは通常、オフサイトで、テープに保存され、保持期間が長くなります。通常、dbインフラストラクチャとバックアップの世話をするさまざまなスペシャリストやチームもいます。この場合、ベリファイアの暗号化は明らかに、宅配会社がテープをオフサイトに移動することによってテープが失われることからの追加の保護になります。
ベリファイアを暗号化する場合、暗号化キーをどこに保持してバックアップするかという問題があります。銀行などの大企業は、SSLキーとパスワード、およびその他の機密性の高いセキュリティ構成について、この問題を解決する必要がありました。それらは、dbバックアップと同じテープにそれらを置きません。通常、彼らは前線ホストを管理できる分離されたセキュリティネットワークを持ち、ネットワーク上の2つのデータセンターにunison/rsyncによってミラーリングされた2つのホスト（または2つの専用NFSヘッド）を持ち、暗号化キーとセキュリティ構成のコピーをバックアップします。 。
これらすべてをまとめると、ホストレベルのバックアップから除外された、アプリケーションサーバー上の安全な構成の場所または共有が必要になります。その場所に、アプリケーションサーバーのユーザーIDに対してのみ読み取り可能な対称キーを配置します。次に、アプリケーションはそれを使用して、ユーザーのSRPベリファイアがメインデータベースに保存/ロードされるときに、それを暗号化/復号化します。各データセンターの隔離されたホストにバックアップするキー。すべてを完全に失うと、オフサイトのテープからデータベースを再構築し、新しい対称鍵を作成します。ユーザーはすべてログインできなくなり、パスワードリセットロジックを使用して新しいベリファイアを設定します。