今はどうですか？ 最も典型的な状況は、サーバーがユーザーパスワードH（pwd）をハッシュデータベースに保存し、認証プロセス中にユーザーからパスワードを受信し、ハッシュを計算して標準と比較することです。 パスワード自体ではなく、パスワードハッシュ値をデータベースに保存すると、悪意のある管理者またはサードパーティの違反者による認証データの盗難から身を守ることができます。 ただし、これにもかかわらず、認証中は毎回、パスワードは通信チャネルのクリアチャネルで送信されます。 また、パスワードを傍受すると、攻撃者は対応するアカウントにフルアクセスできます。 パスワードの傍受を防ぐために、 ダイジェスト認証メカニズムが考案されました。 理解しやすいように、アルゴリズムを少し単純化しました。 各セッションで、サーバーはランダムなRndをクライアントに送信し、クライアントは応答としてH（Rnd + H（pwd））を送信します。 その結果、インターセプトは攻撃者に何も与えませんが、今では弱点があります-サーバーデータベースです。 データベースまたはパスワードハッシュに保存されているパスワードを使用すると、認証に必要なクライアントの応答を再作成できます。 このようなデータベースの盗難は、認証メカニズムのセキュリティに対する深刻な脅威になります。
以下は、追加の脅威を作成せずに、送信されたパスワードが傍受されるのを防ぐ方法の例です。 同時に、小さな変更はサービスにのみ影響し、ユーザーには影響しません。
だから：
- サーバーは、クライアントH（pwd）のパスワードハッシュをデータベースに保存します。
- クライアントはログインをサーバーに送信します。
- サーバーは、クライアントのH（pwd）で暗号化されたランダムなRnd番号をクライアントに送信します。
- クライアントはパスワードを使用してランダムなRnd番号を計算し、ランダムなRnd番号を使用してpwdパスワードを暗号化し、サーバーに送信します。
- サーバーは、乱数Rndを使用してクライアントパスワードを復号化し、パスワードハッシュを計算して標準と比較します。
理解しやすい人のために、コードを読むことは例です。 PHPのサーバー側。 クライアント-Javascript。 また、 デモを見ることができます。 Chrisa Venessライブラリ上に構築されたAES暗号化
もちろん、このソリューションは万能薬ではなく、httpsを使用する方法がない場合にのみ使用するのが理にかなっています。 ただし、説明されているアルゴリズムを使用すると、送信されたパスワードがスニッフィングおよびMitM攻撃から保護されます。
パート2