为什么快递柜取件要”扫码 + 输尾号”两步？——这是 Challenge-Response 认证，不是多余！

ice 加密技术 2026 年 6 月 29 日

你站在丰巢柜前，微信扫一下屏上二维码，柜门”咔”一声弹开——这属于常规操作。

但有时候（尤其是首次取件、或者柜机走”安全校验”模式时），扫码之后屏幕还会多问一句：”请输入手机号后四位”，或者”请输入取件码末位”。

这时候你大概率心里嘀咕过一句：扫码不就已经认出是我了吗？为啥还要多这一步？是产品经理 KPI 凑交互吗？

不是。

这两步合起来，恰好是一个教科书级的 Challenge-Response（挑战-响应）认证，而且它防的那个攻击场景，比你想象的常见。

先把快递柜这条链路拆成协议原语

我们拿”扫码 + 输尾号”这套走一遍角色映射：

快递柜动作	协议里的角色	干什么用
你点屏幕 → 出二维码	Verifier（验证方）下发 Challenge	二维码里绑了一个一次性 session nonce，等价于”这次取件事务的唯一质询值”
你微信扫它	建立 claimant–verifier 信道	此时柜机只知道”有人来取了”，但还不知道来的人是谁——二维码贴在那，谁都能扫，别人拍你截图也能扫
你输手机号后四位 / 取件码末位	Claimant（声称者）拿 Pre-shared Secret 作答 Response	这个 secret 是你寄柜时丰巢用”手机号+运单”绑好的预共享凭证
柜机验 Response → 开门	Verifier 用同一 secret 复算，匹配则放行	标准 C-R 的第六步：Authentication Outcome

💡 关键点：扫码那一下只完成了”认柜 + 拉会话”，没完成”认人”。真正完成身份认证的是”输尾号”那一下——它证明你是那个和丰巢预共享了 secret 的 claimant，而不是路过拍了二维码的路人。

为什么要这么绕？直接扫开不行吗？

不行，因为二维码本身是明文广播的。

想象一个场景：你站在柜前扫码，后面排队的哥们手机镜头一抬，把你屏幕上的二维码拍走了。他走到另一个小区同品牌的柜机前？不行，session 绑了柜号和时序。但他打开你这张二维码的图片，在你这台柜机上重扫一次——如果柜机设计成”扫到就开”，那他就能把你的件取走。

这就是 Replay Attack（重放攻击）的典型场景：攻击者不破解你的密钥，他只是把上次合法的认证报文再发一遍。

Challenge-Response 怎么扛这个？靠 Nonce（一次性随机数）：

柜屏每次出的二维码里塞一个随机 challenge，单次有效，过期/用过就废；

但光有 nonce 还不够——如果”扫到二维码 = 直接开门”，那攻击者只要在你扫码那一瞬间把 challenge 截了（比如拍屏），他自己抢先扫一次就能重放成功；

所以第二步必须加 Response：你用只有你跟丰巢知道的 secret（手机号后四位，或取件码本身）对这次 challenge 做应答，柜机验完才开门。

📌 划重点：Challenge 即使被截，Response 离了 secret 算不出来。这就是 C-R 防重放的核心——也是 CHAP（挑战握手认证协议）在同一条链路里干的事。

这套 pattern 你天天都在用，不止快递柜

C-R 的五元组（Verifier / Claimant / Challenge / Response / Secret）几乎是身份认证界的”乐高底座”，换个皮到处都是：

WiFi 输入密码连网：路由器发 challenge，你输的 PSK 就是 secret，四次握手那一套就是 C-R 的亲戚；

ATM 插卡输密码：卡号识别你（claimant 上线），PIN 是 secret，后台 challenge 验完吐钱；

银行 OTP / 动态令牌：服务端扔一个 challenge（有时就是时间戳+序列号），你手里的 token 用预置 key 算 response；

SSH key 登录：服务器发随机 challenge，客户端用私钥签名回 response，公钥验签——这是 C-R 的非对称版本。

快递柜的”扫码 + 输尾号”是这个家族里最平民化的一次实现：challenge 是二维码（含 nonce），secret 是手机号后四位这种弱但够用的预共享值，response 是你在触屏上敲的那几位。

那为什么不搞成”纯扫码免输”？

确实，很多场景下丰巢/菜鸟走的是”App 已登录 + 微信 OAuth 态 + 手机号已绑”，扫码那一刻 App 已经在 HTTPS 信道里把 secret（登录 token）代你答给后台了——第二步被 App 替你做了，所以你感觉”一步到位”。

但柜机自己没法 100% 依赖这个：

你用的是访客模式 / 没装 App / 微信没授权 —— 后台没你的登录态，只能走”输尾号”降级；

风控触发（比如这个柜今天异常取件率高、或者你这单是贵重件标记过）——强制走 C-R 双因子，宁可多一步也别被重放；

跨品牌互通（丰巢柜 + 菜鸟 App，或反过来）——两边 session 不一定互信，尾号是兜底。

换句话说：你觉得”多余”的那一步，是协议在替你扛”别人拍了你二维码”那种重放。柜机没法假设每个扫码的人都是你，所以它要你拿 secret 应答一下——这和 CHAP 在 PPP 链路上”每隔一段随机时间再扔一次 challenge 重验一次对端”是同一个思路，只不过快递柜把”周期性重验”压缩成了”取件那一刻的一次性双因素”。

下次再遇到柜机让你输尾号，别烦。

它在做的，跟 30 年前 CHAP 在 PPP 链路上干的、跟此刻你连公司 WiFi 时 WPA2 四次握手干的、跟 SSH 用 ed25519 签名 challenge 干的——是同一件事：
Verifier 扔一个只有这次有效的 nonce 过来，Claimant 拿只有你们俩知道的 secret 算一下回过去。多了这一步，重放攻击就死了。

快递柜没那么性感，但密码学有。