PAP認証とは？仕組み・脆弱性・実務での対策を徹底解説

2025年12月12日 最終更新日時 : 2025年12月12日 エバープレイ編集部

概要：PAP認証とは何か

PAP（Password Authentication Protocol）は、ユーザー名とパスワードを用いてリモート認証を行う非常にシンプルなプロトコルです。主にPPP（Point-to-Point Protocol）などのリンク層で使われ、ダイヤルアップやPPPoE、古いVPN実装などで歴史的に広く採用されてきました。PAPは認証の仕組みが単純で実装が容易ですが、認証情報を平文で送信するため現代のセキュリティ要件から見ると多くの脆弱性があります。

PAPの動作フロー（基本的な手順）

PAPはチャレンジ・レスポンス型ではなく、送信側（クライアント）が自分のIDとパスワードを認証サーバに送信し、サーバがOK/NGを返すというワンショットの手順で完結します。標準的な手順は次の通りです。

  • リンク確立：まずLCP（Link Control Protocol）によるPPPリンクの確立が行われます。LCPネゴシエーションの段階で認証方式（PAPやCHAPなど）が決められます。
  • 認証要求：クライアントはPAPのAuthenticate-Requestパケットを送信し、自身のユーザー名（Peer ID）とパスワードを含めます。
  • 認証応答：認証側（サーバ）は内容を検証したのち、Authenticate-Ack（成功）またはAuthenticate-Nak（失敗）を返します。
  • 以後の処理：成功ならIP等のネットワーク層の設定処理へ進み、失敗ならリンクが切断されるか再試行となります。

PAPパケットの構造（概略）

PPP上のPAPメッセージは非常に単純です。一般的な構造は以下のフィールドで構成されます：

  • Code（1バイト）：Authenticate-Request=1、Authenticate-Ack=2、Authenticate-Nak=3 など。
  • Identifier（1バイト）：応答と照合するための識別子。
  • Length（2バイト）：パケット全体の長さ。
  • Peer-ID（文字列）：長さバイト + 実際のユーザー名。
  • Password（文字列）：長さバイト + 実際のパスワード。

重要なのは、ユーザー名やパスワードは暗号化されずに送られる点です（単純な長さプレフィックスで区切られているのみ）。

PAPの利点

  • 実装が簡単で互換性が高い：多くの古い機器やISPの設備でサポートされています。
  • 相互運用性：極めてシンプルなため古いシステム間でも認証が行える。
  • オーバーヘッドが小さい：処理が軽く、計算資源の少ないデバイスでも利用可能。

PAPの主な脆弱性と攻撃パターン

PAPはその単純性ゆえにセキュリティ面で重大な問題があります。主な脆弱性を列挙します。

  • 平文送信（盗聴）：ユーザー名とパスワードが暗号化されずに送られるため、パケットキャプチャ（パッシブスニッフィング）によって認証情報が簡単に盗まれます。
  • リプレイ攻撃：認証メッセージをそのまま再送することで認証を通過できる可能性があります（リンク上での対策がない場合）。
  • なりすまし（MITM）：中間者攻撃により認証サーバになりすましたり、やり取りを改変することが可能です。
  • オフライン総当たり（傍受後）：プレーンテキストが得られればそのまま辞書攻撃やブルートフォースができるほか、RADIUS等のバックエンドに渡す際の処理の弱さによって更なるリスクが生じます。

これらの理由から、機密性が要求される環境ではPAPは推奨されません。

CHAPやEAPなどとの比較

PAPの直接的な代替としてよく比較されるのがCHAP（Challenge-Handshake Authentication Protocol）やEAP（Extensible Authentication Protocol）です。

  • CHAP：サーバがランダムなチャレンジを送り、クライアントはパスワードとチャレンジを組み合わせたハッシュを返す方式です。パスワード自体は送られないため、パスワードがそのまま盗まれるリスクは低減されます。さらに継続的にチャレンジを行い接続中の再認証が可能な点も利点です。ただし、チャレンジ/レスポンスが傍受されるとオフラインで総当たりされ得る点やMD5など古いハッシュの脆弱性にも注意が必要です。
  • EAP：フレームワークであり、EAP-TLS（クライアント証明書）やEAP-PEAP、EAP-TTLSなどより安全な方法を用いることで強固な認証を実現できます。無線LAN（802.1X）や多様なVPNでの採用が進んでいます。

実務での利用例と現状のベストプラクティス

かつては多くのISPのPPPoE接続やダイヤルアップでPAPが使われましたが、現在は以下のような原則が一般的です。

  • インターネットや公共回線を経由する接続ではPAPを避ける。代わりにCHAPやEAP、TLS/IPsec等の暗号化された認証方式を採用する。
  • どうしてもPAPをサポートする必要がある場合は、リンク全体をTLS/IPsecでトンネリングして認証情報を保護するか、物理層やリンク層が信頼できる閉域網内に限定する。
  • バックエンド認証サーバ（RADIUS等）を使用する場合は、RADIUSの通信とシークレット管理を適切に設定し、不要なPAP透過を避ける。
  • 監査ログやパケットキャプチャの監視を行い、認証失敗や異常な再試行がないかを監視する。

RADIUSとPAPの関係

RADIUS（Remote Authentication Dial-In User Service）は認証情報の集中管理に使われます。RADIUSがPAP認証をプロキシする形で使われることがあり、クライアント→NAS（Network Access Server）→RADIUSサーバの流れの中でPAP認証情報がRADIUSのAccess-Request属性として送られます。RADIUSプロトコル自体はユーザー・パスワード属性を共有シークレットとMD5を用いてある程度隠蔽しますが、その保護はエンドツーエンドの暗号化ではなく、RADIUS共有シークレットの管理に大きく依存します。したがってRADIUSを使っていてもPAPを直接使う場合は注意が必要です。

実例：PAPが残存している場面と移行戦略

産業機器、組み込みデバイス、古いルータやモデムの中にはPAPしかサポートしていない機器が残っています。全てを一度に置換するのが難しいケースも多いため、暫定的な対策として次のような施策が考えられます。

  • ネットワークセグメントを分離し、PAPを使う機器は閉域網や隔離されたVLANに限定する。
  • 端末やNASと認証サーバ間の通信をVPN/SSLで保護することで認証情報の盗聴リスクを低減する。
  • 可能ならファームウェア更新やプロキシを導入して、より安全な認証方式（CHAPやEAP）にブリッジする。

まとめ：いつPAPを使うべきか、何を避けるべきか

PAPは設計が古く、認証情報を平文で送信するため機密性の観点からは推奨できません。レガシーサポートが唯一の理由で残されていることが多く、新規導入やインターネットを介した接続にはCHAP、EAP、TLS、IPsecなどの暗号化・相互認証を伴う手段を選ぶべきです。やむを得ずPAPを使う場合は、リンクやバックエンドを暗号化する、ネットワークを分離する、監査とログ管理を徹底するなどの補助的対策を講じてください。

参考文献

Password Authentication Protocol - Wikipedia（日本語）

RFC 1334 - PPP Authentication Protocols

RFC 1661 - The Point-to-Point Protocol (PPP)

RFC 1994 - PPP Challenge Handshake Authentication Protocol (CHAP)

RFC 2865 - RADIUS

カテゴリー
IT
前の記事
【完全解説】LCP交渉（PPP） — 意味・仕組み・オプション・トラブルシュートNew!!
2025年12月12日
次の記事
CHAP認証とは何か：仕組み・脆弱性・運用上の注意点を徹底解説New!!
2025年12月12日