CHAP認証とは何か:仕組み・脆弱性・運用上の注意点を徹底解説
概要:CHAP認証とは
CHAP(Challenge-Handshake Authentication Protocol)は、主にPPP(Point-to-Point Protocol)環境で用いられるチャレンジ・レスポンス型の認証プロトコルです。相手から送られるチャレンジ(乱数)に対して、クライアントが共有秘匿(通常はパスワード)とチャレンジを組み合わせて算出したハッシュ値を返し、認証側が同じ計算を行って照合する方式です。平文パスワードを直接送信しない点でPAP(Password Authentication Protocol)より安全ですが、暗号的強度・実装や運用次第で脆弱になる点が特徴です。
基本的な動作の流れ
CHAPの典型的な認証フローは次の通りです:
- 1. 認証器(サーバまたはNAS)がクライアントに対してチャレンジパケットを送る。パケットには識別子(Identifier)とチャレンジ値が含まれる。
- 2. クライアントは自分のパスワード(共有秘匿)と受け取ったチャレンジ、識別子を使ってハッシュを計算し、レスポンスを返す。一般的にはMD5が用いられる(RFC 1994参照)。
- 3. 認証器は同じ計算(保有するユーザ情報を用いる)を行い、返ってきたレスポンスと照合する。合致すれば認証成功、異なれば失敗を通知する。
- 4. セッション中に再認証(periodic re-challenge)を行うことができるため、接続維持中の乗っ取りを防ぎやすい。
プロトコルとパケット構造の要点
CHAPパケットはPPP上で動作し、パケットフィールドとしてCode、Identifier、Length、Value-Size、Value(チャレンジまたはMD5ダイジェスト)、Nameなどを持ちます。MD5の出力は16バイト(128ビット)で、レスポンスにはこのMD5値が含まれます。チャレンジ値のサイズは実装により異なり得ますが、RFC準拠の実装では可変長(1〜255バイト)です。
数学的な計算式(概念)
CHAPのレスポンス算出は概念的に次のようになります(実装に依存する順序はあるが、基本は同様):
response = MD5(Identifier || password || Challenge)
ここでIdentifierは再生攻撃検出のための1バイトの識別子、passwordは共有秘匿、Challengeは認証器が送ったランダム値です。重要なのは、パスワード自体はネットワーク上に送られないという点です。
CHAPの利点
- パスワードを平文で送らないため、PAPより安全。
- 認証器が任意のタイミングで再チャレンジできるため、長時間接続でのセッション乗っ取りリスクを低減できる。
- 実装が比較的単純で既存のPPPインフラやRADIUS等と連携しやすい。
知られている脆弱性と攻撃手法
CHAPは決して万能ではなく、幾つかの弱点が指摘されています。
- オフライン辞書攻撃/総当たり攻撃:攻撃者がチャレンジとレスポンスのペアを盗聴できれば(例えばPPPトンネルの外部でキャプチャされた場合)、パスワードの推測は容易になる。特にパスワードが短く単純であれば事実上破られる。
- MD5の限界:CHAPで標準的に使われるMD5は衝突に弱いことが知られているものの、衝突攻撃はCHAPのレスポンス算出(主にプリイメージ攻撃)に直接結びつくわけではない。ただし、MD5は現在推奨されないハッシュ関数であり、将来的な脆弱性発見が認証の安全性に影響するリスクは残る。
- 相互認証の欠如(最小限):原則的にCHAPは認証器がクライアントを認証するためのもので、クライアントが認証器を検証する仕組みは限定的である。これにより中間者(MITM)による認証器偽装の危険がある。
- 実装依存の弱点:Microsoft系のMS-CHAPやMS-CHAPv2の実装に関しては既知の弱点が存在し、特にMS-CHAPv2は特定の手法で容易にクラックできることが示されている(後述)。
MS-CHAP と MS-CHAPv2 — Microsoftの拡張と問題点
MS-CHAPはMicrosoftが定めたCHAP互換の拡張で、MS-CHAPv2(RFC 2759)が広く使われました。MS-CHAPv2は相互認証の仕組みを取り入れたことや、NTパスワードハッシュ(NTLMハッシュ)を利用する点が特徴です。しかし、研究者や攻撃者の解析により、MS-CHAPv2のハンドシェイクは実質的にDES鍵の弱点に還元されてしまい、現代の計算資源やクラウドサービスを用いることで現実的な時間でパスワードを復元できることが示されました。これによりMS-CHAPv2は安全とは言えない扱いとされています。
RADIUSとの連携と運用上の注意
CHAPはNAS(Network Access Server)からRADIUSサーバへ認証要求を転送する際にも用いられます。RADIUSではCHAP-Password属性等を介してやり取りされますが、重要なのはRADIUSとNAS間の共有シークレットや接続自体の保護です。RADIUSの共有シークレットが漏洩すると認証プロセス全体が危険に晒されるため、IPsecやTLSでRADIUSトラフィックを保護するなどの運用対策が必要です。
実運用における推奨事項(ベストプラクティス)
- 可能ならばCHAPやMS-CHAPv2の使用は避け、より強固な認証方式(EAP-TLS、EAP-TTLS、PEAP、証明書ベースの認証等)を採用する。
- どうしてもCHAPを使う必要がある場合は、強力なランダムチャレンジと短期間での再認証を設定し、パスワードポリシーを厳格化して複雑で長いパスワードを強制する。
- RADIUSやNASといった機器間通信はTLS/IPsecで保護し、共有シークレットは定期的に変更する。
- MS-CHAPv2は既知の弱点があるため新規導入を避け、既存環境でも可能な限り移行計画を立てる。
- 多要素認証(MFA)を導入し、認証の層を増やすことでパスワード漏洩時の被害を限定する。
現代のセキュリティ観点での評価
CHAPは設計当初(主にダイヤルアップや初期のPPP)では実用的であったものの、今日の攻撃能力や暗号分析を考慮すると単独では十分とは言えません。特にMD5やMS-CHAPv2に代表される古い実装は脆弱と見なされ、組織レベルではEAP系の証明書ベースあるいはTLSで保護された認証メカニズムへ移行することが推奨されます。一方で、レガシー機器や互換性の都合でCHAPを残さざるを得ない環境もあるため、前述の運用上の対策を厳格に適用することでリスクを最小化することが必要です。
まとめ
CHAPはチャレンジ・レスポンス方式という概念的に強力なアイデアを持ち、PAPよりは安全ですが、利用されるハッシュ関数(MD5)や派生実装(MS-CHAPv2)の弱点、運用ミスによって脆弱になり得ます。現代のベストプラクティスは、可能な限りCHAPに頼らず、証明書ベースの認証やTLSで保護されたEAP方式、そして多要素認証を採用することです。レガシー環境でCHAPを使わざるを得ない場合は、強力なパスワードポリシー、RADIUS/NAS間の保護、定期的な再認証などを徹底してください。
参考文献
- RFC 1994 - The PPP Challenge Handshake Authentication Protocol (CHAP)
- RFC 2759 - Microsoft PPP CHAP Extensions
- RFC 2865 - RADIUS
- CloudCracker: MS-CHAPv2 weaknesses and cracking (analysis & cloud service)
- NIST Special Publication 800-63 Digital Identity Guidelines


