web-dev-qa-db-ja.com

サーバーからユーザー名とソルト付きパスワードのペアを取得した場合、ログインできますか？

私はソルトチャレンジレスポンス認証メカニズム（SCRAM）を研究しています。

https://tools.ietf.org/html/rfc5802#page-8 の説明によると、クライアントはプレーンテキストでパスワードを知る必要がないようです。 SaltedPasswordを知っていれば、ClientProofを計算するのに十分です。

つまり、データベースからソルトパスワードを取得できた場合、パスワードをブルートフォースで強制することなくログインできます。

この点でSCRAMの私の理解は正しいですか？

authenticationhashpbkdf2
7
user7610

免責事項：私は暗号化の専門家ではないので、この回答は限られた人からのものですプロトコルの理解

プロトコルを見てみましょう

SaltedPassword  := Hi(Normalize(password), salt, i)
ClientKey       := HMAC(SaltedPassword, "Client Key")
StoredKey       := H(ClientKey)
AuthMessage     := client-first-message-bare + "," +
                    server-first-message + "," +
                    client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof     := ClientKey XOR ClientSignature
ServerKey       := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)

最初に何を知っているか？

  • サーバーは知っています：salt、i、StoredKey、ServerKey
  • クライアントは知っています：パスワード
  • 両当事者は、交換の一部としてAuthMessageを知っています。

答え

すべてを計算するために必要なのはSaltedPasswordだけですが、問題はそのSaltedPasswordを誰も保存しないことです。また、単にクライアントを偽装する場合は、ClientKeyだけでサーバーをだますことができます。

SCRAMの背後にある考え方->失敗？

インターネットアプリケーションプロトコルで最も広く展開および使用されている安全な認証メカニズムは、トランスポート層セキュリティ（TLS）で保護されたチャネルを介したクリアテキストパスワードの送信です。そのメカニズムには、TLSで保護されたチャレンジレスポンス認証メカニズムを使用することで対処できる重要なセキュリティ上の懸念があります。

それでも、サーバーからパスワードを保護する方法については説明されていないようです。なんらかの派手なチャレンジレスポンスメカニズムを使用してパスワードを「決して」送信しない場合でも、ブラウザーページでパスワードを入力すると、サーバーによって提供されるため、ページ内のスクリプトはそのことを理解する必要があります。パスワードが記録されていないことが通知されても、パスワードを記録することを決定できます。

ユーザーにとってのチャレンジ/レスポンスメカニズムの主な利点は、ユーザーがどこでも同じパスワードを再利用できることです。しかし、ユーザーはパスワードを入力したページを本当に信頼できないため、パスワードを再利用することはできません。

次に、私が考えることができる次の大きな利点は、チャレンジ/レスポンスメカニズムでは通常、パスワードがサーバーに保存されないことです。したがって、攻撃者がサーバーのコピーを盗んだとしても、パスワードのハッシュ化を試みることはできません。繰り返しますが、サーバーにはStoredPassword、salt、および反復回数のコピーがあるため、これは大きな失敗です。彼は辞書やブルートフォース攻撃を介してパスワードを解読するために必要なすべてを持っています。

ある時点で、なぜサーバーにパスワードを提供しないのか、疑問に思う必要があります。追加される唯一の保護は、TLSが破られた場合（ただし、攻撃者はリッスンしかできない）、アクセスを取得するために攻撃者はパスワードをブルートフォースする必要があります。

4
Gudradain