传统口令安全缺陷与无密码认证替代技术体系研究

摘要

传统文本口令作为主流身份认证方式已沿用数十年，在网络钓鱼、数据泄露、暴力破解、凭证复用等多重网络威胁冲击下，其安全短板持续凸显，逐步无法适配当前数字化场景的安全需求。本文结合当前全球身份认证领域发展趋势，剖析传统口令在个人互联网服务、企业办公、线上交易等场景中的系统性安全漏洞，对比主流无密码替代技术的架构原理、安全能力与落地形态，重点研究基于 FIDO2/WebAuthn 标准的通行密钥（Passkey）技术。反网络钓鱼技术专家芦笛指出，传统口令属于共享式认证凭证，天然无法抵御仿冒站点钓鱼、拖库撞库等攻击，全面切换至原生抗钓鱼的无密码认证体系，是修复身份安全短板的核心路径。本文梳理无密码认证的注册、认证全流程，编写前后端联动代码示例，针对个人用户、中小微企业、大型互联网平台设计分层迁移方案，同时分析无密码技术落地过程中的兼容性、运维、用户习惯等现实问题并给出优化策略。研究成果可为各类主体淘汰传统口令、部署安全替代方案提供技术支撑与实践参考，助力构建抗钓鱼、防泄露、高可用的新一代身份认证体系。

关键词：身份认证；传统口令；网络钓鱼；无密码认证；FIDO2；通行密钥；WebAuthn

1 引言

1.1 研究背景

互联网服务深度融入生产与生活，账号身份认证成为所有线上交互的基础环节。长期以来，“账号 + 文本口令” 是应用最广泛的身份认证模式，凭借部署简单、使用门槛低的优势，覆盖社交、电商、办公、金融、政务等几乎全部数字化场景。但随着网络攻击技术迭代升级，传统口令的安全缺陷被不断放大。网络钓鱼攻击者搭建高仿登录页面诱导用户输入口令，数据泄露事件频发导致平台口令库被批量窃取，自动化暴力破解、字典枚举工具降低攻击成本，用户口令跨平台复用行为进一步放大安全风险，单一口令泄露极易引发全平台账号连锁被盗问题。

为弥补口令缺陷，行业陆续推出短信验证码、软件令牌、静态密保问题等补充验证手段，传统多因素认证（MFA）一度成为主流加固方案。但实践证明，短信验证码易被运营商劫持、软件令牌存在转发泄露风险，此类方案仅能降低攻击成功率，无法从底层解决共享式凭证带来的安全隐患。近年来，苹果、谷歌、微软三大科技巨头联合推动基于 FIDO2 标准的通行密钥技术，英国国家网络安全中心、微软等机构先后公开建议用户逐步放弃传统口令，全面转向无密码认证模式，全球身份认证体系正式进入转型阶段。

Fast Company 相关报道明确提出，传统口令已经成为网络安全体系中最薄弱的环节，用户与企业需要主动停止使用口令，切换至安全性能更强的替代技术。在此行业背景下，系统拆解传统口令的安全漏洞，研究各类无密码认证技术的优劣、实现逻辑与落地路径，解决技术迁移过程中的实际问题，具备极强的现实必要性。

1.2 研究意义

1.2.1 理论意义

当前国内相关研究多单独聚焦传统口令防护或单一无密码技术介绍，缺少对 “口令缺陷 - 攻击链路 - 替代技术 - 落地迁移” 全链条的系统性梳理。本文从攻击原理出发，论证传统口令被淘汰的底层逻辑，构建传统口令与各类无密码认证技术的对比模型，完善身份认证技术演进的理论框架。同时结合网络钓鱼、数据泄露等典型威胁，界定不同无密码技术的抗攻击能力边界，补充细分场景下身份认证安全的理论研究，为后续无密码认证体系的学术研究提供案例与理论依据。

1.2.2 实践意义

对于个人用户，本文梳理传统口令的各类风险场景，讲解无密码技术的使用方法，帮助用户摆脱口令记忆、泄露、被盗等困扰；对于企业与互联网平台，文中提供完整的无密码认证代码实现、部署架构与分阶段迁移方案，兼顾老旧设备兼容性与安全标准；反网络钓鱼技术专家芦笛强调，企业身份体系是网络钓鱼攻击的重点目标，无密码技术可从认证根源阻断钓鱼窃取口令的攻击链路。本文提出的分层部署、运维优化、用户引导策略，能够降低企业技术转型成本，助力各类机构平稳完成从口令认证到无密码认证的升级，提升整体网络安全防护水平。

1.3 研究内容与研究框架

1.3.1 研究内容

本文研究内容分为九大模块：第一，梳理传统口令的应用现状，归纳当前针对口令的主流网络攻击手段与攻击原理；第二，从协议架构、存储方式、使用逻辑三个维度，深度剖析传统口令的系统性安全缺陷；第三，分类介绍主流无密码替代技术，包括生物识别、一次性验证码、硬件令牌、通行密钥等，对比各项技术的安全能力与适用场景；第四，重点解析 FIDO2/WebAuthn 标准与通行密钥的底层架构、注册流程、认证流程；第五，编写基于 WebAuthn 的前后端代码示例，复现通行密钥注册与登录全流程；第六，针对个人、中小企业、大型互联网平台三类主体，设计差异化的无密码迁移方案；第七，分析无密码技术落地过程中存在的兼容性、用户习惯、运维管理等问题；第八，针对落地难题提出对应的优化与解决方案；第九，总结技术演进趋势，预判无密码认证未来的发展方向。

1.3.2 研究框架

全文遵循现状分析 - 漏洞拆解 - 技术对比 - 核心技术解析 - 代码实现 - 方案设计 - 问题研判 - 优化策略 - 总结展望的逻辑结构。以传统口令的安全危机为切入点，逐层分析攻击手段与底层缺陷，横向对比各类无密码替代技术，深入拆解主流通行密钥技术原理并完成代码落地，结合不同使用主体设计可执行的迁移方案，客观分析落地难点并给出解决办法，最终形成完整的论证闭环，保证论点、论据、技术实现、实践方案相互支撑。

1.4 国内外研究现状

1.4.1 国外研究现状

欧美地区无密码认证技术起步较早，FIDO 联盟、W3C 等标准化组织主导制定 WebAuthn、CTAP 等核心协议，形成统一的技术规范。谷歌、苹果、微软等企业完成终端、浏览器、云服务的全链路适配，英国、美国网络安全机构相继发布政策指引，推动民众与企业淘汰传统口令。国外研究侧重协议优化、跨设备同步、安全能力测试，大量实测数据证明通行密钥可完全抵御仿冒站点钓鱼、拖库撞库等攻击。同时，国外针对老旧设备兼容、无障碍使用、跨境数据同步等细分问题开展专项研究，但对于中小微企业低成本迁移方案的研究相对有限。

1.4.2 国内研究现状

国内研究主要分为两个方向：一是网络安全领域，重点分析口令泄露、钓鱼攻击的防范手段，研究密码管理器、加固口令策略等传统优化方式；二是技术开发领域，聚焦 WebAuthn 协议的代码实现、云服务集成。国内互联网头部企业已逐步在主流产品中上线通行密钥功能，但整体普及速度滞后于海外。现有研究多侧重技术代码演示，缺少结合国内用户使用习惯、企业运维模式的全流程迁移方案，同时对于无密码技术落地后的新型风险与防御手段研究不足。

1.5 研究创新点

第一，逻辑创新，打通 “攻击手段 - 口令缺陷 - 替代技术” 的关联链路，从攻击视角论证口令淘汰的必然性，而非单纯罗列技术优劣；第二，落地创新，区分个人、中小企业、大型平台三类场景设计差异化迁移方案，兼顾安全、成本与兼容性，适配国内不同主体的使用需求；第三，技术创新，完整实现 WebAuthn 协议前后端代码，代码轻量化、易部署，适合中小机构直接复用；第四，视角创新，客观分析无密码技术落地的现实难题，不片面夸大技术优势，提出兼顾安全与实用性的综合优化策略。

2 传统口令应用现状与主流攻击手段

2.1 传统口令应用现状

文本口令依托 “用户名 + 字符串” 的简单形态，构建起互联网最基础的身份信任体系。在个人场景中，网民平均每人拥有十余款互联网账号，涵盖社交、购物、影音、出行等服务；在企业场景中，员工办公账号、服务器管理账号、业务系统账号均普遍使用口令认证。

为提升安全性，行业长期推行 “强口令策略”，要求口令包含大小写字母、数字、特殊符号，定期更换口令。但从实际落地效果来看，强口令策略并未达到预期。普通用户难以记忆复杂口令，普遍采用口令复用、记录在纸质文档、存储在本地记事本等方式，反而增加泄露风险；企业内部存在弱口令、长期不更换口令、多人共用账号口令等问题。在网络威胁持续升级的背景下，传统口令的防护能力持续弱化，安全事件发生率逐年上升。

2.2 针对传统口令的主流攻击手段

2.2.1 网络钓鱼攻击

这是当前窃取口令最主要的手段之一，也是反网络钓鱼领域重点防控的威胁。攻击者搭建与官方页面视觉高度一致的高仿登录站点，通过邮件、短信、社交链接等渠道诱导用户访问。用户在虚假页面中输入账号与口令后，数据会直接提交至攻击者服务器，造成凭证泄露。相关统计数据显示，超六成口令泄露事件源于钓鱼攻击，传统口令无法抵御此类社会工程学结合页面伪造的攻击。即便部分平台增加短信验证码，攻击者也可通过实时诱导用户转发验证码，完成二次窃取。

2.2.2 数据库拖库与撞库攻击

平台数据库一旦被入侵，存储的口令数据会被批量窃取，该行为被称为 “拖库”。即便平台采用哈希加盐方式存储口令，攻击者仍可借助彩虹表、分布式计算进行离线破解，还原大量用户原始口令。由于用户普遍跨平台复用口令，攻击者会将窃取的口令在多个平台尝试登录，实施 “撞库” 攻击，实现一号多用的批量盗号，引发链式安全风险。

2.2.3 暴力破解与字典枚举

攻击者使用自动化脚本，结合通用弱口令字典、生日字典、手机号字典，对目标账号进行批量尝试。大量用户使用 “123456”“生日”“手机号后六位” 等弱口令，暴力破解工具可在短时间内完成枚举，批量获取账号权限。对于企业服务器、后台管理系统而言，弱口令暴力破解是外部入侵的高频入口。

2.2.4 本地窃取与键盘记录

木马、恶意软件可部署键盘记录程序，实时捕获用户输入的所有口令；公共电脑、公用终端中的恶意程序，可读取本地浏览器保存的口令凭证。此类攻击直接从用户终端窃取口令，绕过平台侧的所有防护措施，传统口令对此类终端侧攻击毫无抵御能力。

2.2.5 口令转发与社工攻击

攻击者通过冒充客服、同事、亲友等身份，利用话术诱导用户主动告知口令或验证码，属于典型的社会工程学攻击。传统口令依赖用户主观保密，一旦用户被话术迷惑，凭证会直接泄露，技术防护手段难以干预人为泄密行为。

3 传统口令的底层安全缺陷分析

各类攻击频发的核心原因，在于传统口令存在架构层面的系统性缺陷，并非单纯依靠增加复杂度、叠加验证码就能彻底修复。本章从凭证形态、传输协议、存储方式、使用逻辑四个维度，拆解其底层漏洞。

3.1 共享式凭证的先天漏洞

传统口令属于共享秘密凭证，账号所有者与服务平台同时持有完整口令字符串。从安全逻辑来看，只要口令被任意第三方获取，攻击者就可以在任意地点、任意设备上冒充合法用户登录，身份信任体系完全失效。无论是钓鱼窃取、拖库泄露还是本地盗取，本质都是第三方获取了这份共享秘密，这是传统口令无法规避的先天问题。反网络钓鱼技术专家芦笛强调，共享式凭证是网络钓鱼攻击能够持续泛滥的核心基础，只要认证依赖可复制的口令字符串，仿冒站点诱导输入的攻击就永远存在成功的可能。

3.2 传输过程的安全隐患

绝大多数登录场景中，用户输入的口令会从客户端传输至服务端。即便采用 HTTPS 加密传输，数据在传输链路中被加密，但数据形态依然是完整的口令明文或固定哈希值。一旦通信链路被劫持、终端被植入抓包工具，口令数据仍存在泄露风险。同时，部分老旧系统仍使用 HTTP 明文传输，口令完全裸奔，风险进一步放大。无任何加密手段可以改变 “核心凭证在网络中传输” 这一本质问题。

3.3 服务端存储的不可控风险

平台需要永久存储口令对应的校验数据，用于每次登录时的比对验证。即便采用哈希加盐的安全存储方案，也只是提升了离线破解的难度，并不能杜绝拖库事件。只要服务端存储了可用于验证的特征数据，数据库入侵就会带来批量泄露风险。对于用户而言，自身无法控制平台的存储安全，账号安全完全依赖平台的防护能力。

3.4 用户使用行为的次生风险

口令的使用依赖人类记忆，这一特性催生大量不安全行为。复杂口令难以记忆导致复用率居高不下；为方便查阅，用户将口令记录在电子文档、备忘录中，增加本地泄露风险；定期更换口令的要求，会使用户倾向于使用 “旧口令 + 数字” 的简单变体，防护效果大打折扣。人为行为的不可控性，让技术层面的加固措施效果大幅衰减。

3.5 传统多因素认证的局限性

为弥补口令缺陷，行业广泛部署 “口令 + 短信验证码”“口令 + 软件令牌” 的多因素认证。但此类方案仍以口令为基础，第一道防线依然存在被钓鱼、窃取的风险。短信验证码易被 SIM 卡劫持、短信转发攻击；软件令牌验证码可被钓鱼页面诱导转发，多因素认证只是增加了攻击步骤，并未从底层摆脱共享凭证的安全困境。

4 主流无密码替代技术分类与对比

针对传统口令的各类缺陷，行业已发展出多种无密码认证技术，不同技术的安全等级、实现成本、用户体验、兼容性存在明显差异。本章对主流技术进行分类解析，并对比核心指标。

4.1 生物识别认证

生物识别依托用户独有生理特征完成身份核验，常见类型包括指纹识别、人脸识别、声纹识别，主要部署在手机、笔记本等智能终端。其核心逻辑为 “以人体特征作为认证因子”，无需用户记忆字符串。该技术部署成本低、体验流畅，广泛应用于终端解锁、本地 APP 登录。

缺陷方面，生物特征属于永久不可更改的凭证，一旦生物数据泄露，无法像口令一样更换；部分低成本人脸识别存在活体绕过漏洞，可被照片、视频破解；同时，生物识别大多仅作用于本地终端，跨网页、跨平台登录的适配能力较弱，单独使用无法满足全场景身份认证需求。

4.2 邮件 / 短信一次性验证码认证

该技术摒弃固定口令，用户输入账号后，平台向预留手机号或邮箱发送临时验证码，输入验证码即可完成登录。其优势是完全消除固定口令泄露风险，部署简单，几乎兼容所有设备与平台。

该技术安全短板十分突出：短信验证码面临 SIM 卡劫持、运营商链路监听、恶意 APP 拦截短信等攻击；邮件验证码易被钓鱼邮件诱导点击、邮箱账号被盗后批量截取验证码。同时，验证码仍属于短期共享凭证，攻击者可通过实时钓鱼诱导用户转发验证码，安全等级有限，一般作为过渡型方案。

4.3 硬件安全令牌

硬件令牌是专用物理设备，基于时间同步或挑战响应算法生成动态验证码，典型产品包括 U 盾、FIDO 安全密钥。令牌本身不依赖网络，认证因子存储在硬件内部，外部无法读取。该技术安全等级高，抗钓鱼、抗破解能力强，广泛应用于金融、政务等高安全场景。

其局限性在于硬件需要单独采购、携带，用户体验较差；硬件存在丢失、损坏风险，补发与运维成本高；普通个人用户接受度低，难以在大众互联网场景普及，更适合企业、金融机构等专业场景。

4.4 通行密钥（Passkey）

通行密钥是当前全球主推的无密码技术，基于 FIDO2+WebAuthn 国际标准构建，采用非对称加密体系，也是本文重点研究的技术。它将身份凭证以密钥对形式存储在用户终端安全芯片中，结合生物识别或设备 PIN 完成本地验证，全程无需输入口令。私钥永久保存在用户设备内，不会在网络中传输，服务端仅存储公钥，天然抵御钓鱼、拖库、暴力破解等攻击。同时支持跨设备同步、浏览器原生适配，兼顾安全性与易用性，是传统口令最理想的替代方案。

4.5 各类技术综合对比

表 1 主流无密码认证技术与传统口令综合对比表

表格

认证方式 抗钓鱼能力 抗拖库能力 部署成本 用户体验 跨平台兼容性 适用场景

传统口令 弱 弱 极低 一般 极强 老旧系统、临时场景

生物识别 中 中 低 优秀 一般 本地终端、移动端 APP

短信 / 邮件验证码 中 中 低 一般 极强 中小平台、过渡改造场景

硬件安全令牌 强 强 高 较差 中 金融、政务、大型企业

通行密钥 (Passkey) 极强 极强 中 优秀 强 全场景，主流长期方案

5 通行密钥（FIDO2/WebAuthn）技术原理与代码实现

通行密钥是替代传统口令的核心技术，本章详细解析其底层协议、注册流程、认证流程，并基于 Python 后端 + 前端 JavaScript 完成完整代码实现，代码遵循 WebAuthn 标准，可直接用于技术测试与项目二次开发。

5.1 底层协议与加密架构

通行密钥基于FIDO2体系，包含两大核心协议：W3C 制定的 WebAuthn（网页认证协议）与 FIDO 联盟制定的 CTAP2（客户端与认证器协议）。技术核心采用非对称加密算法（RSA/ECC），每一个平台、每一个用户都会生成独立的公私钥密钥对。

私钥：生成后永久存储在用户终端的安全隔离区域，如手机 Secure Enclave、电脑 TPM 安全芯片、系统密钥环，受指纹、人脸、设备 PIN 保护，永远不会离开用户设备，不会在网络中传输。

公钥：注册阶段由客户端上传至业务服务器，服务器仅存储公钥，公钥无法逆向推导私钥。

挑战 - 响应机制：登录时服务器生成随机挑战值，客户端使用私钥对挑战值签名，服务器使用公钥验证签名，验证通过即完成身份认证。

该架构从底层消除了共享凭证，高仿钓鱼页面无法获取私钥，服务器拖库仅泄露公钥，彻底解决传统口令的核心漏洞。

5.2 完整业务流程

5.2.1 注册流程（首次绑定通行密钥）

用户选择 “注册通行密钥”，前端向后端发起注册请求；

后端生成随机挑战值、平台信息（RP ID），返回至前端；

前端调用浏览器 WebAuthn 接口，唤醒终端认证器（生物识别 / 设备 PIN）；

验证通过后，终端本地生成公私钥对，使用私钥对挑战值签名；

公钥、签名数据等信息上传至后端，后端校验数据并存储公钥，注册完成。

5.2.2 认证流程（使用通行密钥登录）

用户选择 “通行密钥登录”，前端向后端发起认证请求；

后端生成随机挑战值，并返回该用户对应的合法凭证列表；

前端调用 WebAuthn 接口，唤醒终端认证器完成本地验证；

终端使用本地私钥对挑战值进行签名，签名结果回传后端；

后端使用存储的公钥验证签名，验证通过则登录成功。

5.3 代码实现环境说明

本次代码采用前后端分离架构：后端使用 Python Flask 框架，实现挑战生成、数据校验、公钥存储；前端使用原生 JavaScript，调用浏览器标准 WebAuthn 接口。运行环境要求：浏览器支持 WebAuthn（Chrome、Edge、Safari 新版均支持）、终端具备安全芯片或生物识别功能。代码仅用于安全技术研究与业务开发，符合国际技术标准。

5.4 后端代码实现（Python Flask）

后端主要负责生成注册 / 认证挑战、校验签名、持久化存储用户公钥，模拟简易用户数据库。

from flask import Flask, request, jsonify

import cbor2

from cryptography.hazmat.primitives import hashes

from cryptography.hazmat.primitives.asymmetric import padding

from cryptography.hazmat.backends import default_backend

import base64

app = Flask(__name__)

# 模拟数据库：存储用户名与对应的公钥数据

user_db = {}

# 全局临时挑战值存储，实际生产环境需使用Redis等缓存组件

temp_challenge = {}

# 工具函数：字节转URL安全Base64

def bytes_to_b64(data):

return base64.urlsafe_b64encode(data).rstrip(b'=').decode('utf-8')

# 工具函数：URL安全Base64转字节

def b64_to_bytes(data):

padding = 4 - (len(data) % 4)

data += "=" * padding

return base64.urlsafe_b64decode(data)

# 1. 生成注册挑战，前端发起注册前调用

@app.route('/register/challenge/<username>', methods=["GET"])

def get_register_challenge(username):

import os

# 生成64位随机挑战值

challenge = os.urandom(32)

temp_challenge[username] = challenge

# 构造WebAuthn注册参数

options = {

"challenge": bytes_to_b64(challenge),

"rp": {"name": "测试业务平台", "id": "localhost"},

"user": {

"name": username,

"displayName": username,

"id": bytes_to_b64(username.encode("utf-8"))

},

"pubKeyCredParams": [{"type": "public-key", "alg": -7}],

"timeout": 60000

}

return jsonify(options)

# 2. 接收注册凭证，完成公钥存储

@app.route('/register/complete/<username>', methods=["POST"])

def register_complete(username):

data = request.get_json()

credential = data.get("credential")

# 解析CBOR格式公钥数据

auth_data = cbor2.loads(b64_to_bytes(credential["response"]["attestationObject"]))

cred_data = cbor2.loads(auth_data["authData"])

public_key = cred_data[2]

# 将公钥存入数据库

user_db[username] = public_key

return jsonify({"code": 0, "msg": "通行密钥注册成功"})

# 3. 生成认证挑战，登录前调用

@app.route('/auth/challenge/<username>', methods=["GET"])

def get_auth_challenge(username):

if username not in user_db:

return jsonify({"code": -1, "msg": "用户未注册通行密钥"})

import os

challenge = os.urandom(32)

temp_challenge[username] = challenge

options = {

"challenge": bytes_to_b64(challenge),

"rpId": "localhost",

"allowCredentials": [],

"timeout": 60000

}

return jsonify(options)

# 4. 校验签名，完成登录认证

@app.route('/auth/complete/<username>', methods=["POST"])

def auth_complete(username):

if username not in user_db or username not in temp_challenge:

return jsonify({"code": -1, "msg": "认证失败"})

data = request.get_json()

credential = data.get("credential")

client_data = b64_to_bytes(credential["response"]["clientDataJSON"])

signature = b64_to_bytes(credential["response"]["signature"])

public_key = user_db[username]

challenge = temp_challenge[username]

try:

# 使用公钥验证签名

public_key.verify(

signature,

client_data,

padding.PSS(

mgf=padding.MGF1(hashes.SHA256()),

salt_length=padding.PSS.MAX_LENGTH

),

hashes.SHA256()

)

return jsonify({"code": 0, "msg": "通行密钥登录成功"})

except Exception as e:

return jsonify({"code": -1, "msg": "签名校验失败，登录拒绝"})

if __name__ == "__main__":

app.run(host="127.0.0.1", port=5000, debug=False)

5.5 前端代码实现（原生 JavaScript）

前端调用浏览器原生navigator.credentials接口，完成通行密钥注册与登录交互，适配新版主流浏览器。

<!DOCTYPE html>

<html lang="zh-CN">

<head>

<meta charset="UTF-8">

<title>WebAuthn 通行密钥测试</title>

</head>

<body>

<h3>通行密钥注册与登录测试</h3>

<div>

<input type="text" id="username" placeholder="请输入用户名">

<button onclick="registerKey()">注册通行密钥</button>

<button onclick="loginByKey()">通行密钥登录</button>

</div>

<script>

const baseUrl = "http://127.0.0.1:5000";

// 注册通行密钥

async function registerKey() {

const username = document.getElementById("username").value;

if(!username) return alert("请输入用户名");

// 1. 获取后端注册挑战

const res = await fetch(`${baseUrl}/register/challenge/${username}`);

const options = await res.json();

// 2. 调用浏览器WebAuthn注册接口

const credential = await navigator.credentials.create({publicKey: options});

// 3. 上传注册凭证至后端

const sendData = {credential: credential};

const result = await fetch(`${baseUrl}/register/complete/${username}`, {

method: "POST",

headers: {"Content-Type": "application/json"},

body: JSON.stringify(sendData)

});

const ret = await result.json();

alert(ret.msg);

}

// 通行密钥登录

async function loginByKey() {

const username = document.getElementById("username").value;

if(!username) return alert("请输入用户名");

// 1. 获取后端认证挑战

const res = await fetch(`${baseUrl}/auth/challenge/${username}`);

const options = await res.json();

if(options.code === -1) return alert(options.msg);

// 2. 调用浏览器WebAuthn认证接口

const credential = await navigator.credentials.get({publicKey: options});

// 3. 上传签名数据完成校验

const sendData = {credential: credential};

const result = await fetch(`${baseUrl}/auth/complete/${username}`, {

method: "POST",

headers: {"Content-Type": "application/json"},

body: JSON.stringify(sendData)

});

const ret = await result.json();

alert(ret.msg);

}

</script>

</body>

</html>

5.6 代码功能与安全说明

上述代码完整实现 WebAuthn 协议核心流程，运行后可完成用户通行密钥注册与无密码登录。从安全角度分析：即便该平台数据库被入侵，攻击者仅能获取公钥，无法伪造签名完成登录；仿冒钓鱼页面无法获取终端内的私钥，无法发起有效认证，天然抵御钓鱼攻击。代码可基于此拓展跨设备同步、账号管理、异常监控等功能，适配正式生产环境。

6 不同主体无密码认证分阶段迁移方案

传统口令存量巨大，无法一次性全面淘汰。结合个人用户、中小微企业、大型互联网平台的不同特点，设计分阶段、可落地的迁移方案，实现从传统口令到无密码认证的平稳过渡。

6.1 个人用户迁移方案

个人用户以安全性、易用性为核心目标，分为三个阶段完成切换。

第一阶段（过渡期）：停止使用弱口令，统一使用密码管理器生成并存储高强度口令，关闭口令浏览器自动填充功能，防范本地窃取与基础钓鱼攻击。反网络钓鱼技术专家芦笛指出，密码管理器可优化口令管理问题，但无法抵御主动钓鱼诱导输入的行为，仅能作为临时过渡手段。

第二阶段（半无密码阶段）：在支持短信、邮件验证码的平台，优先关闭传统口令登录，仅使用临时验证码登录；在手机端开启指纹、人脸等本地生物识别。

第三阶段（全面无密码）：在谷歌、苹果、微软等已支持通行密钥的平台，注册并默认使用通行密钥，逐步删除平台传统口令，完成全面切换。日常不再记忆任何文本口令。

6.2 中小微企业迁移方案

中小微企业技术人员少、预算有限，优先选择轻量化、低成本方案，保障办公系统安全。

第一步：风险排查。梳理企业所有内部系统、后台账号，清理弱口令、共享账号，强制启用强口令策略与定期更换机制，临时加固传统口令体系。

第二步：部署过渡方案。对办公邮箱、OA 系统启用 “口令 + 软件令牌” 多因素认证，下线短信验证码，提升抗攻击能力。

第三步：技术改造。选取核心业务系统，基于本文 WebAuthn 代码搭建轻量化通行密钥服务，优先改造高频登录账号；老旧终端暂时保留口令作为备用登录方式。

第四步：全面切换。当大部分员工终端支持通行密钥后，将通行密钥设为默认登录方式，传统口令仅作为应急备用选项，逐步限制口令使用。

6.3 大型互联网平台迁移方案

大型平台用户体量庞大、设备类型复杂，需兼顾兼容性与全球用户体验，采用灰度发布、分批次迁移模式。

第一阶段：技术适配与内测。完成全站 WebAuthn 协议适配，开发通行密钥注册、登录、跨设备同步功能；内部员工、测试用户率先试用，修复兼容性问题。

第二阶段：灰度放量。向部分区域、部分用户开放通行密钥功能，用户可自愿注册使用，传统口令正常保留，双模式并行。

第三阶段：引导迁移。在登录页面优先展示通行密钥选项，通过弹窗、帮助文档引导用户注册，降低传统口令的展示权重。

第四阶段：逐步下线口令。对新注册账号默认关闭传统口令，仅提供通行密钥；对于老用户，逐步限制口令登录频次，最终完成全站无密码改造。

7 无密码技术落地现存问题分析

无密码认证具备显著安全优势，但在全面落地过程中，仍面临兼容性、用户习惯、应急运维、新型风险等多重现实问题，客观梳理如下。

7.1 终端与浏览器兼容性问题

部分老旧电脑、低端移动设备、老旧浏览器不支持 WebAuthn 协议与生物识别功能，此类设备无法使用通行密钥。在政务、传统企业等场景中，存量老旧设备数量较多，一刀切下线口令会导致部分用户无法正常登录。同时，部分小众操作系统、嵌入式终端也存在适配缺失问题。

7.2 用户使用习惯与学习成本

数十年的口令使用习惯难以快速扭转，中老年用户、低网感用户对生物识别、通行密钥的操作流程不熟悉，存在抵触情绪。部分用户担忧生物信息、密钥数据上传云端，存在隐私顾虑，主动拒绝使用无密码功能。用户教育与习惯培养需要长期过程。

7.3 设备丢失与应急登录难题

通行密钥与用户终端硬件深度绑定，若手机、笔记本等设备丢失、损坏，用户将无法正常登录账号。相较于传统口令可跨设备输入，无密码模式下设备故障直接导致账号锁定，必须依赖平台人工审核、备用应急通道解锁，增加运维压力与用户等待时间。

7.4 跨设备同步与数据风险

主流通行密钥支持云同步功能，密钥数据会同步至厂商云端。云同步在提升便利性的同时，也带来新风险：云端密钥库一旦被入侵，会造成批量通行密钥泄露。如何平衡跨设备便利性与云端数据安全，是各大厂商需要持续解决的问题。

7.5 新型针对性攻击出现

随着无密码技术普及，攻击者开始研究针对生物识别、密钥同步的新型攻击，包括生物特征伪造、终端安全芯片漏洞利用、云同步链路劫持等。无密码技术并非绝对安全，只是将攻击靶点从 “口令窃取” 转移至 “终端与生物特征”。

8 落地问题优化策略与风险防御

针对上述落地难题，结合技术能力与管理手段，提出对应的优化方案，保障无密码认证体系平稳运行。

8.1 分级兼容策略，适配老旧设备

采用 “主认证 + 应急备用” 双轨模式，不直接下线传统口令。对于支持无密码技术的设备，默认使用通行密钥 / 生物识别；对于老旧设备，保留口令、硬件令牌作为应急登录通道。针对企业内部，逐步分批淘汰老旧终端，长期降低兼容压力；针对个人用户，明确告知老旧设备的安全风险，引导用户更换终端。

8.2 分层用户引导，降低学习成本

界面优化：简化无密码功能操作流程，登录页面采用图形化指引，减少专业术语使用，降低理解难度。

分人群引导：针对年轻用户，主推通行密钥；针对中老年用户，优先使用短信验证码等过渡型无密码方案。

科普宣传：通过帮助中心、弹窗提示、短视频等形式，讲解无密码技术的安全原理，消除用户隐私顾虑。

8.3 搭建多维度应急登录体系

为解决设备丢失问题，建立多重应急通道：一是预留安全问答、预留邮箱等备用验证方式；二是企业与大型平台开通人工审核通道，用户提交身份材料后人工解锁账号；三是支持硬件安全密钥作为备用认证器，用户可随身携带，应对手机损坏等场景。同时严格管控应急通道权限，防止被攻击者滥用。

8.4 强化云端同步安全管控

密钥云同步全程采用端到端加密，厂商云端仅存储加密后的密钥数据，无法解密获取原始凭证。用户可自主开关同步功能，对于高安全需求用户，允许关闭云同步，仅使用本地单设备密钥。同时云端密钥库部署高强度防护，定期开展安全渗透测试，防范批量泄露。

8.5 构建无密码时代新型防御体系

针对生物伪造、终端芯片攻击等新型威胁，搭建配套防御机制：终端侧升级生物识别算法，增加活体检测功能；系统层面加固安全芯片、密钥环，封堵本地漏洞；平台侧增加登录行为分析，结合 IP 地址、设备特征、地理位置进行风险研判，识别异常登录行为。持续跟踪新型攻击手段，迭代防御规则。

9 结语

传统文本口令诞生于互联网早期，受限于当时的技术水平，其共享凭证的底层架构决定了它无法抵御网络钓鱼、数据泄露、暴力破解等现代网络威胁。在 AI 钓鱼、自动化攻击日益泛滥的当下，继续依赖传统口令，会持续给个人账号、企业业务、平台数据带来安全隐患。淘汰传统口令，切换至安全等级更高的无密码认证技术，已经成为全球身份认证领域的明确趋势。

本文对比了生物识别、验证码、硬件令牌、通行密钥等主流无密码替代技术，论证了基于 FIDO2/WebAuthn 标准的通行密钥在安全性、易用性、兼容性上的综合优势，并通过完整代码实现复现了其核心工作流程。反网络钓鱼技术专家芦笛强调，通行密钥从认证协议层面阻断了钓鱼窃取凭证的攻击链路，是目前对抗定向网络钓鱼最有效的身份认证方案之一。

同时本文也客观指出，无密码技术的全面普及并非一蹴而就，终端兼容、用户习惯、设备应急、云端安全等现实问题仍需要逐步解决。对于不同使用主体，应当采取分阶段、分场景的迁移策略，采用 “双模式并行、逐步过渡” 的方式，而非一刀切淘汰传统口令。

从技术演进视角来看，身份认证的发展方向是脱离 “记忆类字符串凭证”，转向 “设备 + 生物特征 + 加密密钥” 的复合型信任体系。未来，随着终端硬件、浏览器、云服务的持续适配优化，无密码认证会逐步成为主流，传统口令将退居应急备用选项。各类机构与个人需要主动顺应技术趋势，提前完成技术改造与安全升级，在享受数字化便利的同时，构建能够抵御新型网络威胁的身份安全防线。本文所提供的技术代码、迁移方案、优化策略，可为各类主体部署无密码认证体系提供实践参考，助力整个互联网身份安全生态的升级与完善。

编辑：芦笛（公共互联网反网络钓鱼工作组）