パスワードがサーバーですでにハッシュされている場合、ナンスでハッシュされたパスワードを確認しますか？

Question

ウィキペディアでこの写真を見つけました nonce 記事：

パスワードを平文で送信することを避け、リプレイ攻撃を防ぐために、パスワードはサーバーからの1つの乱数（nonce）とクライアントからの1つ（cnonce）とともにハッシュされます。私は、両方の乱数を知っているサーバーが同じハッシュを計算し、比較して検証すると仮定します。

私の質問は：

サーバーにパスワードがプレーンテキストで保存されていない場合、これは機能しません。サーバーでパスワードがすでに（ソルトアンドペッパーで）ハッシュされている場合、サーバーがハッシュを検証する方法を確認できません。
このスキームを拡張して、ハッシュされたパスワードを何らかの方法で機能させることはできますか？
塩とコショウを使用すると、これがさらに複雑になりますか？

Neil Smithline · Accepted Answer

サーバーにパスワードがプレーンテキストで保存されていない場合、これは機能しません。サーバーでパスワードがすでに（ソルトアンドペッパーで）ハッシュされている場合、サーバーがハッシュを検証する方法を確認できません。

このスキームでは、パスワードをクリアテキストで保存する必要があります。ひどい。

このスキームを拡張して、ハッシュされたパスワードを何らかの方法で機能させることはできますか？

きっと可能ですが、必要はありません。参照したスキームは HTTPダイジェスト認証プロトコルです。 SSLが多くのシステムに実装するにはコストがかかると考えられた日に書かれました。ダイジェスト認証は、パスワードを公開せずにクリアテキストチャネルを介してログインする方法を提供しました。これを行う理由はまったくありません。 SSLは事実上無料です。

一般に、サーバーにパスワードを保存するリスクは、サーバーがパスワードをメモリ内に短時間（パスワードメッセージの受信からハッシュ化が始まるまでの時間とクリアテキストのパスワードのメモリ）保持しないことの利点を上回っていると考えられます。消去できます）。

クライアント側のハッシュが意味のある状況がいくつかあります。たとえば、LastPassは、クライアントとサーバーの両方のハッシュを含む一意の認証メカニズムを実装しています。暗号化キーを作成するための基礎としてパスワードを使用し、サーバーが暗号化キーをサーバーに知られたくないためです。だから彼らがすることは：

強力な暗号化キーを作成するためのクライアントでのPBKDF2の多くのラウンド。
暗号化キーを効果的にパスワードに変換するSHA-256の1ラウンド。
サーバーにパスワードを送信します。 SHA-256のプロパティにより、パスワードを暗号化キーに戻すことが計算上不可能になることに注意してください。
サーバーはPBKDF2とソルトを使用して標準のサーバー側ハッシュを実行します。

基本的に、LastPassサーバーは標準のパスワードを保存しますが、「パスワード」として取得するのはクライアント側のハッシュの結果です。

Steffen Ullrich · Answer

このスキームを拡張して、ハッシュされたパスワードを何らかの方法で機能させることはできますか？

このスキームではありません。動作方法のため、パスワードまたは特定の同等のものが必要です（ https://stackoverflow.com/questions/1000281/storing-password-in-tables-and-digest-authentication for詳細）必要な計算を実行します。

もちろん、単純なアプローチでは、スキーマを変更して、パスワードのハッシュがクライアントですでに行われるようにして、サーバー上のハッシュされたパスワードを比較に使用できるようにすることができます。ただし、この場合、ハッシュされた元のパスワードは基本的に保護する必要のある新しいパスワードになり、元のパスワードはまったく問題になりません。

ハッシュされたパスワードの主な考え方は、データベースのパスワードを保護するための不可逆的な操作があり、ハッシュをデータベースに追加するときに最初に実際のパスワードに対してこの不可逆的な操作を使用し、後で入力したパスワードをデータベースエントリ。つまり、トランスポート（つまり、TLSを使用）またはデータベース（つまり、パスワードを入力してデータベースにクリア）を保護する必要があります。スキームが必要な場合は、データベースを保護することもトランスポートを保護することもできず、公開鍵暗号化を試してください。

Silverfox · Answer

安全なチャネル、つまりTLSを使用している場合は、この種のトリックを実行する必要はありません。

最初の質問については、はい、そうです。このスキームでは、サーバーがパスワードをクリアテキストでアクセスして、再現できるようにする必要がありますH（nonce + cnonce + password）。
2つ目の質問については、リプレイ攻撃にさらされない方法は考えられません（ただし、私はこの分野では得意ではありません）。
いいえ、ソルトを追加しても、サーバー側にハッシュのみがある場合よりも複雑になることはありません。（プレーンパスワードを持っている場合-持っていない場合、このシナリオでは-ソルトの有無にかかわらずハッシュの計算はそれほど変わりません）。