从 43 秒到 5 秒：NHS login 如何改造登录，为什么仍保留短信验证码？

一次登录，从输入密码、等待短信，再填写验证码，缩短到调用设备解锁，究竟改变了什么？NHS login 与 Hippo 的公开复盘给出的两个数字是：旧方式的登录中位耗时 43 秒，采用通行密钥 Conditional UI 的方式为 5 秒。但如果只把这件事总结成“加了指纹登录，所以速度提高”，就漏掉了项目中更难的部分：用户如何开通、设备不支持怎么办、凭据失效怎么办，以及为什么仍然需要保留短信路径。

本文沿着原项目的真实界面和官方迭代记录拆解这些问题。它是一则外部公开项目分析，顾问网没有参与 NHS 的交付，也没有访问其生产后台。文中分别标明“项目披露”“界面观察”和“技术分析”；没有公开的数据，不补写成事实。

一、先认识案例：这不是一个可以轻易要求用户重新注册的系统

NHS login 是英国数字公共服务中的统一身份入口。它需要让不同设备、不同数字熟练程度的人访问相关服务，登录失败会直接阻断后续使用。交付方 Hippo 的早期项目介绍把它描述为跨服务的身份基础设施；这意味着改造的对象不仅是一个表单，而是已经承担大量实际访问的账户体系。

对于这样的系统，新方案不能只照顾熟悉新设备的用户。已有账户要继续能用，原有身份核验与登录会话要衔接，换设备或丢设备的人也要有恢复路径。把所有人强制转成新方式，可能减少了产品内部的分支，却把问题推给了用户。

二、旧流程卡在哪里：43 秒不能简单归因于“网络慢”

原项目对比的是密码加短信验证码与通行密钥登录。前一种流程需要把记忆、输入和消息接收串在一起：用户得记住或找回密码，设备要能收到短信，随后还要返回页面完成验证。任何一步中断，都可能把一次登录变成找回密码、重新发送或求助。

这里需要克制解释：公开资料没有给出 43 秒中“输入密码占多少、等短信占多少”的原始拆分。因此不能编造一张耗时瀑布图，也不能断言主要瓶颈就是短信供应商。我们能确认的是，新方式改变了用户需要完成的动作；具体节省落在哪个阶段，需要项目自己的事件记录才能回答。

技术分析：一个成熟的改造目标应同时包含速度与完成率。仅记录完成者的耗时，可能忽略那些在前面已经放弃的人；只看新方式成功率，又可能漏掉不支持设备的用户。比较前，应先写清计时起点、终点、失败是否计入，以及两组用户是否可比。

三、第一张真实界面：把“注册密钥”放在可信的账户场景里

左侧原图能观察到三个具体设计：页面里有建立通行密钥的入口；提示只在个人或可信设备上设置；点击后由设备提供原生创建弹窗。这些细节说明，用户的动作是在为当前账户建立以后可用的凭据，而不是向一个陌生页面提交生物信息。

原案例披露了在用户完成原方式登录后邀请开通的做法。它的价值不只是“少打扰”：用户已经完成既有认证，新增凭据有明确账户上下文。对于实施团队，仍须按风险要求评估是否需要近期重新认证，不能把“曾经登录过”当成永久允许新增高敏感凭据。可结合官方部署检查清单审查这一入口。

从截图里还可以看到，真正的创建确认留在了设备界面中。这让用户继续使用熟悉的交互，也减少网站自行仿制安全弹窗的空间。网站应解释动作的用途与范围，但不应诱导用户把设备 PIN 输入网页表单。

这一画面也暴露了需要测试的分支：用户取消弹窗时，页面是否保留当前任务？设备没有可用解锁方式时，是否说明如何继续？后端验证失败时，能否避免显示“已经开通”？这些是根据界面提出的验收问题，不是本文声称在 NHS 后台发现了这些故障。

四、第二张真实界面：成功提示必须说明“以后怎么用”

中间的确认页没有停留在抽象的“设置成功”。它告诉用户，可以用设备已有的指纹、面容、解锁码或图案继续登录，并限定为使用这台设备的情境。页面还提供返回登录与安全设置的入口。

界面观察：这段提示解决了用户完成一次陌生操作之后最自然的问题：我刚才做了什么，下次会有什么不同？它没有要求用户记住公钥、私钥或认证器名称，而是把结果连接到已经会做的设备解锁动作。

技术分析：成功页还应有严谨的触发条件。浏览器返回一个凭据对象，只说明前端获得了响应；账户是否已经绑定成功，要以后端验证与保存结果为准。若前端先提示成功，后端保存随后失败，用户下一次登录就会遇到与页面承诺不一致的体验。

同样，图中“在这台设备”不应被改写成“以后所有设备都不用验证”。同步型通行密钥、跨设备认证和账户恢复各有条件；用户理解的范围越清楚，后续支持负担越小。NHS 的官方帮助页也分别解释了本设备、另一设备与丢失设备时的处理。

五、第三张真实界面：看起来像指纹登录，实际依赖公钥认证

右侧画面显示登录页面正在核对资料，设备弹出屏幕解锁请求，并保留使用 PIN 的选择。我们能观察到的事实是：网站流程与设备核验在这里衔接。不能从这张图推断用户必须具备指纹识别，也不能把它解释成 NHS 网站收到了一份指纹图像。

依据 WebAuthn 规范，通行密钥使用与依赖方关联的公钥凭据。设备侧的用户核验帮助控制凭据使用；服务器验证的是认证响应与相应公钥关系。网站的认证成功与设备完成一次解锁，是相关但不同的判断层。

上图是本文依据规范整理的技术分析图，不是 NHS 生产系统架构图。公开项目没有披露完整代码、存储设计或部署拓扑，我们不能替它画出一套声称真实的服务器架构。

从实施角度，至少需要区分两段流程。注册时，服务器给出挑战和选项，浏览器调用设备创建凭据，服务器再验证响应并建立账户关联。登录时，服务器给出新的挑战，设备生成认证响应，后端通过验证后才建立应用会话。

其中不能省略的核验包括挑战是否对应本次请求、来源与 RP ID 是否符合预期、签名是否有效，以及是否满足要求的用户存在或核验标志。挑战需要合适的随机性、有效期和使用约束；这些细节应交给成熟组件并按文档验证，不适合照抄一段演示代码当生产认证。Google 的服务端认证说明给出了核验范围。

六、为什么自动填充入口重要，又为什么不能只加一个 HTML 属性

案例里的 Conditional UI，是把通行密钥选择接入用户熟悉的登录表单，而不是要求所有人先理解自己应该选哪种认证。对于同一站点同时存在密码用户和通行密钥用户的阶段，这能减少一次不必要的预先决策。

技术分析：输入框上的 autocomplete="username webauthn" 只是配合浏览器交互的一部分。完整实现还需要获取服务器选项、检测支持能力，并通过凭据请求设置相应的条件式交互，处理取消、失败和其他登录方式。官方的表单自动填充指南提供了这一完整上下文。

这也解释了为什么不能用“按钮出现了”作为上线验收。应当检查用户从输入框进入原生提示，成功认证后能否建立正确账户会话；如果取消或没有匹配凭据，又能否继续原方式。多个并发认证请求、重复弹窗或过早启动的提示，都可能让新入口增加摩擦。

七、真正的专业复盘，还要追踪成功报道之后发生了什么

只阅读成果文章，容易以为方案已经一次性完成。但 NHS login 官方发布日志保留了更细的产品演进证据：5 月修正自动填充过早启动，6 月限制入口只在支持的设备或浏览器显示，7 月完善限流与取消后的安全码路径，9 月改善尝试耗尽后的页面去向，10 月继续改进凭据删除时的账户管理。

这些记录不能证明方案失败，也不能用于估算总体故障率——发布日志没有提供相应分母。它们能支持更具体的判断：把新认证方式接进真实产品，需要不断调整启动时机、能力判断、错误回退和凭据生命周期，工作量不止在首次调用 API。

例如，限流后直接跳错误页，用户会失去继续完成原任务的路径；保留在登录页并提供仍允许的备选方式，可以把一个技术状态转回可理解的操作。这里的回退不能绕过必要的安全控制，应在同一风险策略下设计，而不是“新方式失败就免验证”。

另一个问题是已撤销凭据仍然出现在设备建议里。服务器已经不接受，用户却仍被设备推荐，结果会像“我明明设置过，为什么不能用”。Signal API 文档讨论了服务端凭据状态与提供方之间的一致性处理；实际使用要检测支持能力，并限制敏感凭据信息的暴露。不能把客户端同步提示当作服务端撤销授权的替代品。

八、43 秒、5 秒与成本节省：哪些结论成立，哪些不成立

原复盘披露了 43 秒与 5 秒的中位登录耗时，并列出累计创建约 670 万个通行密钥、每月约 600 万次相关登录，以及上线以来最高约 120 万英镑的短信 OTP 成本节省。这些是项目公开报告的口径；本文没有原始事件数据，不能进行独立审计。来源见Chrome for Developers 原案例。

从 43 到 5，按这两个数计算的耗时下降约为 88.4%。这个算术关系是成立的，但它不能补出原文没有公开的实验设计。两组是否随机分配、设备结构是否一致、是否排除了失败样本、季节变化如何控制，仍需要原始研究材料才能判断。

因此，更稳妥的专业结论是：该项目披露的采用规模与耗时结果，支持继续研究通行密钥带来的使用价值；同时，官方持续迭代说明可靠性与可达性需要长期维护。我们不能把这组数字直接移植成某个 WordPress 会员站的收益预测。

九、为什么仍保留密码与短信：把恢复路径也算进安全方案

对已有大规模账户体系而言，换设备、没有可用凭据、无法完成本地核验等情形仍然存在。用户能够用通行密钥顺利登录，不代表其他路径可以立即撤除。保留方式和开放条件，需要结合账户风险、设备覆盖及恢复策略决定。

这里有一个常被忽略的边界：如果主认证很强，而找回账户只需一个容易被接管的弱条件，攻击者可能转向恢复入口。项目不能只验收“正常登录更快”，还要检查新增凭据、删除凭据、丢设备和恢复后会话处理。

对于企业网站，应先识别主要风险发生在客户登录、后台管理员还是业务授权。认证回答“这个人是谁”，授权还要回答“这个身份此时可以做什么”。使用了通行密钥，也不能替代服务端权限检查、会话保护和异常操作审核。

十、怎样把这则案例转成自己项目的实施方案

若你准备改造会员站、客户门户或员工入口，先写出旧流程的实际数据，而不是从“装一个插件”开始。需要知道哪些设备在用、失败停在哪一步、用户为什么求助，以及恢复账户平均需要什么操作。没有基线，就很难判断新方式究竟改善了什么。

然后按下面四个阶段推进。它们是根据本案例提出的项目建议，不是 NHS 未公开的内部排期。

1. 定义边界。明确哪些账户可试用、如何建立凭据、撤销后何时失效，以及保留什么备选方式。
2. 跑通完整生命周期。除了正常注册和登录，还要测试取消、设备不支持、失效凭据、限流、跨设备和丢失设备。
3. 小范围观察。记录真实完成率与耗时，同时区分技术失败、用户取消和回退完成，不把它们混成一个失败率。
4. 决定扩大或调整。同时核对安全、完成率、支持工单和成本；不能只凭最快的一次演示决定全量切换。

对 WordPress 或其他现成平台，还应确认扩展是否具备可信维护、兼容的账户关联与恢复机制。通行密钥的引入应当作为账户体系项目来评估；关于认证判断和权限边界，可结合统计插件权限漏洞复盘继续阅读。需要梳理实际站点时，可在网站安全服务范围内明确评估与实施的分工。

资料与图片说明

案例事实以 Chrome for Developers、交付方 Hippo 和 NHS 官方公开资料为依据，核对日期为 2026 年 11 月 2 日。文中三张界面细节图来自原案例的同一张公开三联图，分别对应创建、成功确认和认证画面；仅保真裁切，未改写界面、伪造数据或生成患者资料。它们展示的是原文公开画面，不代表当前所有设备上的最新界面。

原案例作者署名为 Yu Tsuno、Darren Hutton、Pelin Dem；原文对未另行标注的内容采用 CC BY 4.0，代码示例另有许可。界面版权与标识归相应权利方所有，本文只用于案例分析，不表示 NHS 为顾问网背书。封面、认证边界图和迭代时间线由顾问网整理，均明确标注其资料与分析属性。

主要资料：2026 年 7 月案例复盘；Hippo 项目转载；NHS 通行密钥帮助；NHS 2026 发布日志。文中未出现的原始研究、后台日志和完整代码，本文均未声称持有。