web-dev-qa-db-ja.com

古いSRP3プロトコルセットアップの強化

これが状況です。クライアントサーバーログインはSRP3を介して行われ、使用されるハッシュは単一のSHA1です。クライアントは変更できませんが、サーバーは変更できます（オープンソース）。このため、データベース内のすべてのハッシュパスワードはSHA1のみです。サーバーはすでに数回ハッキングされ、データベース全体がリークされ、パスワードが壊れていました。

SRP3が正しく機能するための私の理解では、クライアントとサーバーの両方が同じハッシュアルゴリズムを使用する必要があるため、SHA1をbcryptなどで切り替えることはできません。サーバー側のハッシュを強化するための私のオプションは何ですか？

srp
1
cen

サーバーでは、特別な構造を持つ「パスワード検証者」を保存する必要があります。 SRP 3（ RFC 2945 で説明されているもの）では、これは次のように説明されています。

The Host stores user passwords as triplets of the form

    { <username>, <password verifier>, <salt> }

Password entries are generated as follows:

    <salt> = random()
    x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
    <password verifier> = v = g^x % N

サーバーにvまたはsaltがない場合、プロトコルは機能しません。サーバーはsaltをクライアントに送信する必要があり（プロトコルの最初のステップで）、その後すぐにvを使用する必要があるためです。したがって、サーバーが実際に格納するものに関係なく、サーバーはsaltとvをほんの一瞬で取得または再計算するのに十分な知識を持っている必要があります。サーバーの完全なコピーを取得した攻撃者は、同じことを実行してsaltとvにアクセスし、パスワードに対するブルートフォース攻撃を高速化できます（v、saltを指定すると、usernameの計算が高速になるため、高速になります）。推定パスワードは、SHA-1のカップルとべき剰余のみを意味します）。

したがって、唯一の希望は、攻撃者がnotcompleteを取得する方法を見つけることです。 -）サーバーのコピー。つまり、保存されているデータを「他の場所」に保存するキーで対称的に暗号化し、最善を尽くして祈るということです。たとえば、「SQLインジェクション」説得のほとんどの違反により、攻撃者はデータベースに保存されているサーバーデータの多かれ少なかれ完全なコピーを取得できますが、データベース外の任意のファイルを（すぐに）読み取ることはできません。サーバーが対称暗号化キーをファイルに保存し、そのキーを使用してデータベース内の関連フィールド（つまり、v値）を暗号化すると、データベースのダンプのみを取得する攻撃者は無効になります。

バリアントは、saltとvの値を格納する追加の内部サーバーをセットアップすることです。メインサーバーはそのセカンダリサーバーと通信します。メインサーバーが攻撃者によって完全に乗っ取られた場合、すべての値の徹底的なポンピングの試みを検出するのは、そのセカンダリサーバー次第です。少なくとも、物理的な分離により、機密値（saltおよびv）がSQLインジェクションや同様の違反から保護されます。

クライアントを変更せずにできることはほとんどありません。

1
Tom Leek