web-dev-qa-db-ja.com

安全なリモートパスワードの実装：ベリファイアの構築

RFC 2945 で説明されているSRPプロトコルは、パスワード検証を生成します。

_x = SHA(<salt> | SHA(<username> | ":" | <raw password>))`
v = g^x % N
_

3つの質問があります：なぜSHAを2回使用するのか、なぜユーザー名を使用するのか、なぜセパレーターを追加するのか？これらはx = SHA(<salt> | <raw password>)に実用的なセキュリティを追加しますか？

passwordsauthenticationcryptographyhashkey-exchange
7
jnm2

SHA-1は理想的なハッシュ関数ではありません（実際には、SHA-2関数もそうではありません）。二重ハッシュ呼び出しは、SHA-1の内部の欠点のいくつかを隠します。これは [〜＃〜] hmac [〜＃〜] に似ていますが、これもほぼ同じ理由でダブルハッシュ呼び出しを使用しています。詳細には、ユーザー名とパスワードをxにマップする関数（関数のファミリーの中でsaltによって選択された関数）が動作するようにしますランダムなOracleのように、ハッシュ関数の通常のセキュリティプロパティ（衝突耐性、プレイメージ耐性）は、そのような動作を保証するには不十分です。

ユーザー名は、セキュリティの証明を容易にするために使用されます。これにより、特定のサーバーが複数のユーザーを受け入れ、それぞれが独自のパスワードを持つ場合に発生することを考慮する必要なく、セキュリティ分析を単一のユーザーに集中させることができます。セパレータは同じ目標に参加します。それ以外の場合、パスワードが「ny67dtzo」の「john」とパスワードが「67dtzo」の「johnny」は、セキュリティの観点から同じ世界に住んでいます。

8
Thomas Pornin

複数の文字列をハッシュ関数に入力する場合は常に、セパレーターは優れた暗号設計プラクティスです。たとえば、ユーザー名bob、パスワードbydesignとユーザー名bobby、パスワードdesignの混同を防ぐのに役立ちます。

一般的な設計原則は "ハッシュの前に複数の文字列を連結するときは注意してください" です。あなたはそのリンクでより詳細な説明を見つけることができます。この設計原則に違反すると過去に欠陥が生じたため、明らかな攻撃を考えることができない場合でも、常に設計原則に従うことをお勧めします。

2
D.W.