# PPP 安全认证题详解，为什么答案是 CHAP 与三次握手

这道题考查的并不是某一种散列算法，而是 PPP 链路中的身份认证协议，以及该协议完成一次认证所需要的报文交互过程。
题目如下。
PPP 的安全认证协议是（32），它使用（33）的会话过程传送密文。
（32）A．MD5　B．PAP　C．CHAP　D．HASH
（33）A．一次握手　B．两次握手　C．三次握手　D．同时握手
正确答案为
（32）选择 C，CHAP
（33）选择 C，三次握手
完整组合就是
PPP 的安全认证协议是 CHAP，它使用三次握手的会话过程传送经过单向散列计算得到的认证响应值。
这里的「传送密文」属于教材为了便于出题而采用的概括性说法。按照严格的密码学术语，CHAP 传送的并不是通过加密算法生成、可以使用密钥解密还原的密文，而是根据随机挑战值、共享秘密和标识符计算出来的单向散列响应值。这个区别对理解 CHAP 的安全机制很重要。
## PPP 为什么需要身份认证

PPP 的英文全称是 Point-to-Point Protocol，也就是点对点协议。它主要用于在两个直接相连的通信节点之间传送网络层数据报。
PPP 曾经广泛应用于电话拨号上网、专线互联、路由器串行链路以及宽带接入。后来常见的 PPPoE，也就是 PPP over Ethernet，同样沿用了 PPP 的链路建立、身份认证和网络层参数协商思想。许多早期的 ADSL 宽带连接要求输入宽带账号和密码，其后台认证过程就可能使用 PAP、CHAP 或运营商扩展出来的认证机制。
一条 PPP 链路从建立到传输 IP 数据，并不是插上线缆便立即开始发送业务数据。它通常会经历链路建立、身份认证、网络层协议配置和链路终止等阶段。
链路建立阶段使用 LCP，也就是 Link Control Protocol，协商最大接收单元、认证协议、链路质量检测等参数。若通信双方协商认为需要认证，链路便进入认证阶段。认证通过以后，才会使用 NCP 配置网络层协议。例如传输 IPv4 时，可以使用 IPCP 协商 IP 地址等参数。
PPP 认证并非在所有场景中强制启用。RFC 1994 说明，PPP 建立数据链路后，可以在进入网络层协议阶段之前执行可选的认证阶段。需要认证时，双方会在链路建立阶段通过认证协议配置选项进行协商。[RFC 1994 对 PPP 认证阶段的说明](https://www.rfc-editor.org/rfc/rfc1994.html)
因此，PPP 和 CHAP 之间不是平行关系。PPP 是完整的点对点数据链路协议体系，CHAP 是 PPP 可以协商采用的一种身份认证协议。
## 为什么第 32 空选择 CHAP

四个选项中，真正需要重点比较的是 PAP 和 CHAP。
MD5 是 Message-Digest Algorithm 5 的缩写，是一种消息摘要算法。它可以参与 CHAP 响应值的计算，但它本身不是完整的 PPP 身份认证协议。一个认证协议除了要规定摘要算法，还要规定由哪一方发起认证、报文如何组织、挑战值怎样产生、响应怎样返回、认证结果如何通知以及认证失败后如何处理。
HASH 是散列计算这一类技术的统称，也不是这里所问的具体 PPP 认证协议。
PAP 是 Password Authentication Protocol，也就是密码认证协议。PAP 确实属于 PPP 认证协议，但它会把用户名和密码直接放进认证请求报文。这里所说的直接发送并不一定表现为肉眼立刻可读的字符串，因为底层仍然会按照网络协议格式编码，但它没有通过挑战值和单向散列机制保护密码。只要攻击者能够截获并正确解析 PPP 帧，就可能取得认证凭据。
CHAP 是 Challenge-Handshake Authentication Protocol，常译为挑战握手认证协议、质询握手认证协议或询问握手认证协议。它不会把共享密码本身放入链路，而是传输根据挑战值和共享秘密计算出的散列响应。
RFC 1994 对 CHAP 的定义非常明确。认证方产生一个随机 Challenge，被认证方根据 Challenge 和秘密值计算经过密码学散列处理的 Response。规范还明确说明，共享秘密不会在链路上传输。[RFC 1994 对 CHAP 工作机制及安全特性的规定](https://www.rfc-editor.org/rfc/rfc1994.html)
从试题的措辞判断，「安全认证协议」和「传送密文」都在提示 CHAP，而不是 PAP。因此，第 32 空选择 C。
## CHAP 的三次握手怎样进行

CHAP 的一次认证过程可以浓缩为三个方向明确的报文动作。
认证方发出 Challenge 挑战报文。被认证方收到挑战后，使用单向散列函数计算响应，并返回 Response 响应报文。认证方独立计算预期结果，比较成功后返回 Success，比较失败则返回 Failure。
这三个动作对应三次报文传递，所以教材把它称为三次握手。
整个过程可以写成下面的顺序。
认证方发送 Challenge
被认证方返回 Response
认证方发送 Success 或 Failure
这里的认证方通常是要求对端证明身份的网络接入设备，被认证方则是需要取得链路使用权限的一端。
RFC 1994 直接将 CHAP 定义为使用 3-way handshake 周期性验证对端身份的协议。规范列出的过程同样分为挑战、散列响应和认证结果三个阶段。[RFC 1994 中的三次握手定义](https://www.rfc-editor.org/rfc/rfc1994.html)
从 CHAP 报文的 Code 字段也可以验证这一点。RFC 1994 规定了四种代码，其中 Code 1 表示 Challenge，Code 2 表示 Response，Code 3 表示 Success，Code 4 表示 Failure。Success 和 Failure 是同一阶段中互斥的两种结果，不是连续发送的第四次和第五次报文。因此，一次正常认证仍然是三次握手。
不少考试题容易在这里制造误导。由于 CHAP 一共定义了四类报文，有人会误以为它是四次握手。实际上，Challenge 和 Response 各占一次，认证方在第三次交互中根据验证结果选择 Success 或 Failure 之一。四种报文类型不等于一次认证必然发送四个报文。
第 33 空因此选择 C，三次握手。
## 散列响应是怎样计算出来的

经典的 CHAP with MD5 会把三个输入按规定次序连接起来，再执行 MD5 运算。
可用简化公式表示为
Response=MD5(Identifier∥Secret∥Challenge)Response = MD5\left(Identifier \parallel Secret \parallel Challenge\right)其中，Identifier 是标识符，Secret 是通信双方预先保存的共享秘密，Challenge 是认证方为本次认证产生的挑战值，符号 ∥\parallel 表示把各段数据依次连接。
RFC 1994 规定，Response Value 是对 Identifier、Secret 和 Challenge Value 的连接结果执行单向散列而得到的。使用 MD5 时，响应值长度为 16 个八位组，也就是 128 位。[RFC 1994 对 Response Value 的格式定义](https://www.rfc-editor.org/rfc/rfc1994.html)
假定接入服务器和拨号终端都预先保存了同一个共享秘密。接入服务器发送一段本次连接专用的随机挑战值，终端把标识符、共享秘密和挑战值组合起来计算摘要。服务器自己也完成相同计算，并将本地结果与收到的 Response 比较。
若两个结果相同，服务器就有理由相信对端掌握正确的共享秘密。因为共享秘密没有直接出现在链路中，监听者不能仅靠复制 Response 得到密码原文。
这类机制可以类比银行柜台核验某个只有双方掌握的计算规则。柜台临时给出一个每次变化的数字，来访者根据秘密规则算出答案，只提交答案而不提交秘密规则。柜台用自己保存的同一规则计算一次，两边答案一致便通过核验。下一次柜台换一个数字，以前截获的答案也就不能直接再次使用。
这个类比只用于帮助理解报文关系。实际 CHAP 使用的是精确定义的字节串、标识符和散列算法，而不是普通算术题。
## 题目中的密文为什么需要谨慎理解

从应试角度看，题目把 CHAP 的 Response 称为密文，目的是突出密码不以明文形式发送。按照这一命题意图，选择 CHAP 没有疑问。
从技术角度看，加密与散列不能混为一谈。
加密通常是可逆过程。明文通过加密算法和密钥变成密文，持有相应密钥的一方可以把密文还原成明文。AES 就是典型的对称加密算法，RSA 则是经典的公钥密码算法。
散列通常是单向映射。输入数据经过散列函数得到固定长度的摘要，正常情况下不能仅根据摘要反向恢复完整输入。CHAP 的认证方也不会把收到的 Response 解密。它会使用自己保存的 Secret 和收到过的 Challenge 再计算一次摘要，通过比较两个摘要是否相同完成判断。
所以，更严谨的表述应当是
CHAP 通过三次握手传送经过单向散列计算的响应值，认证密码本身不在 PPP 链路上传输。
RFC 1994 的摘要部分使用了 cryptographically hashed Response 这一表达，也就是经过密码学散列的响应，而不是 encrypted password。规范还特别说明，认证方法依赖双方知道的秘密值，该秘密值不会通过链路发送。[RFC 1994 的摘要与安全说明](https://www.rfc-editor.org/rfc/rfc1994.html)
理解这个细节，可以避免把 MD5 误选为第 32 空。MD5 只是 CHAP 可采用的散列算法，而 CHAP 才是规定完整三次认证过程的协议。
## PAP 为什么不是本题答案

PAP 同样属于 PPP 身份认证协议，却采用完全不同的交互过程。
PAP 通常表现为两次握手。被认证方主动发送 Authenticate-Request，报文中携带身份标识和密码。认证方检查后返回 Authenticate-Ack 或 Authenticate-Nak。
其顺序可以概括为
被认证方发送账号和密码
认证方返回接受或拒绝
因此，PAP 是两次握手，CHAP 是三次握手。
RFC 1334 同时定义过 PAP 和早期 CHAP。该规范说明，PAP 与 CHAP 都是 PPP 认证协议，但二者的认证方式不同。[RFC 1334 对 PAP 与 CHAP 的定义](https://www.rfc-editor.org/rfc/rfc1334.html)
PAP 的问题不只是握手次数较少，更关键的是密码会直接出现在认证请求中。PAP 不能有效防止窃听，也缺少 CHAP 所采用的动态挑战机制。即使密码只发送一次，只要一次报文被成功截获，攻击者便可能在其他连接中重新使用这组凭据。
这与早期拨号上网的实际场景非常贴近。用户计算机通过调制解调器接入 ISP，接入服务器要求认证。如果使用 PAP，终端把账号和密码送往服务器，链路监听者有机会获得完整凭据。如果使用 CHAP，服务器发出临时 Challenge，终端只返回计算结果，密码本身不会出现在 PPP 帧中。
PAP 的优点在于实现简单，而且服务器可以把收到的密码交给其他身份系统核验。CHAP 的代价则是认证双方必须能够取得共享秘密，服务器不能只保存一种无法参与 CHAP 运算的普通不可逆密码摘要。RFC 1994 也指出，CHAP 要求秘密值能够以可用于计算的形式存在，这是它的一项实现局限。[RFC 1994 对 CHAP 局限性的说明](https://www.rfc-editor.org/rfc/rfc1994.html)
由此可以建立一组稳定的考试记忆关系。
PAP 对应密码直接传递和两次握手。
CHAP 对应挑战响应、散列值传递和三次握手。
## CHAP 如何降低重放攻击风险

如果一种认证系统每次都发送完全相同的认证值，攻击者即使不知道密码，也可能记录一次合法认证报文，日后原样发送。这就是重放攻击的基本思路。
CHAP 在计算 Response 时加入 Challenge。认证方每次发出的 Challenge 应当变化，Identifier 也会随挑战变化。即使同一账号连续连接两次，只要 Challenge 不同，最终生成的 Response 通常也不同。
攻击者截获上一次的 Response，再把它用于新的 Challenge，服务器重新计算出的预期值将与旧 Response 不一致，认证便会失败。
RFC 1994 要求每次发送 Challenge 时改变 Challenge Value，并建议挑战值具有唯一性和不可预测性。规范还明确指出，变化的标识符和挑战值能够提供针对重放攻击的保护。[RFC 1994 对重放攻击防护的说明](https://www.rfc-editor.org/rfc/rfc1994.html)
CHAP 还允许在链路建立以后再次发出 Challenge。认证方可以在网络层协议运行期间重新检查对端身份，而不是只在最初连接时认证一次。这个特征也解释了协议名称中的 Challenge 和 Handshake。
不过，CHAP 并不能自动加密后续业务数据。认证通过只表明对端掌握共享秘密，并不代表整个 PPP 数据链路已经获得机密性保护。后续 IP 数据是否加密，要看链路上是否另行使用 IPsec、TLS、VPN 或其他安全机制。
## 三次握手不要和 TCP 三次握手混淆

CHAP 的三次握手与 TCP 的三次握手都使用「三次握手」这个名称，但目标和报文完全不同。
TCP 三次握手的主要任务是建立可靠传输连接、同步双方序列号并确认收发能力。其典型报文是 SYN、SYN 加 ACK、ACK。
CHAP 三次握手的任务是核验身份。其报文是 Challenge、Response、Success 或 Failure。
二者都存在三个交互步骤，却不能互相替代。TCP 工作在传输层，CHAP 属于 PPP 认证体系中的协议。PPP 通常被归入数据链路层，CHAP 报文也封装在 PPP 数据链路帧的信息字段中。RFC 1994 规定，CHAP 协议字段值为十六进制 C223，一个 PPP 帧的信息字段中封装一个 CHAP 分组。[RFC 1994 对 CHAP 封装格式的说明](https://www.rfc-editor.org/rfc/rfc1994.html)
因此，只凭「三次握手」四个字判断协议非常危险。看到 SYN、ACK 和序列号，应当联想到 TCP。看到 Challenge、Response、Success、Failure 和共享秘密，应当联想到 CHAP。
## 对四个选项逐项判断

A 项 MD5 不正确。MD5 是消息摘要算法，可以供 CHAP 计算 Response 使用，却没有定义完整的 PPP 认证报文交互。
B 项 PAP 不正确。PAP 虽然是 PPP 认证协议，但它采用两次握手，并且会直接传送身份信息和密码，不符合题目强调的安全认证与密文传递特征。
C 项 CHAP 正确。CHAP 是 PPP 的挑战握手认证协议，采用 Challenge、Response、Success 或 Failure 构成的三次握手，并通过单向散列响应避免直接发送共享秘密。
D 项 HASH 不正确。HASH 表示散列技术类别，不是此题所要求的具体 PPP 认证协议名称。
对于第 33 空，一次握手无法完成挑战与响应核验。两次握手更符合 PAP 的请求与确认过程。同时握手不是 CHAP 规范中的认证模式。三次握手与 RFC 1994 的协议定义完全一致，所以选择 C。
## 最终结论

第 32 空选择 C，CHAP。
第 33 空选择 C，三次握手。
考试中可以直接记成一组对应关系。
PAP 使用两次握手，密码认证请求中包含可直接取得的密码信息，安全性较低。
CHAP 使用三次握手，认证方发出随机挑战，被认证方返回散列响应，认证方再通知成功或失败。共享密码本身不会在链路上传送，还能借助变化的 Challenge 和 Identifier 降低重放攻击风险。
题干中的「传送密文」应理解为传送经过单向散列处理的认证响应，而不是传送可以被解密还原的传统密文。按标准术语表达，这道题最准确的完整答案是，PPP 的安全认证协议为 CHAP，它通过三次握手传送密码学散列响应值。

这道题考查的并不是某一种散列算法，而是 PPP 链路中的身份认证协议，以及该协议完成一次认证所需要的报文交互过程。题目如下。PPP 的安全认证协议是（32），它使用（33）的会话过程传送密文。（32）A．MD5　B．PAP　C．CHAP　D．HASH（33）A．一次握手　B．两次握手　C．三次握手　D．同时握手正确答案为（32）选择 C，CHAP（33）选择 C，三次握手完整组合就是PPP 的安全认证协议是 CHAP，它使用三次握手的会话过程传送经过单向散列计算得到的认证响应值。这里的「传送密文」属于教材为了便于出题而采用的概括性说法。按照严格的密码学术语，CHAP 传送的并不是通过加密算法生成、可以使用密钥解密还原的密文，而是根据随机挑战值、共享秘密和标识符计算出来的单向散列响应值。这个区别对理解 CHAP 的安全机制很重要。

PPP 安全认证题详解

这道题考查的并不是某一种散列算法，而是 PPP 链路中的身份认证协议，以及该协议完成一次认证所需要的报文交互过程。题目如下。PPP 的安全认证协议是（32），它使用（33）的会话过程传送密文。（32）A．MD5　B．PAP　C．CHAP　D．HASH（33）A．一次握手　B．两次握手　C．三次握手　D．同时握手正确答案为（32）选择 C，CHAP（33）选择 C，三次握手完整组合就是PPP 的安全

紫薇堂堂主

网络与通信

安全

编程语言

PPP安全认证协议为CHAP，采用三次握手传送单向散列响应值。CHAP通过Challenge-Response机制，认证方发送随机挑战，被认证方返回散列计算结果，避免直接传输密码。相比PAP的两次握手和明文密码传输，CHAP安全性更高，可有效防止重放攻击。题目中"传送密文"指密码学散列响应，而非可解密的传统密文。

对称加密

服务器

路由器

路由

IPsec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PPP 安全认证题详解-腾讯云开发者社区-腾讯云

PPP 安全认证题详解

PPP 安全认证题详解

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐