密码困境与无密码认证
密码并非是当前数字世界才有的产物，诸如故事中的《阿里巴巴与四十大盗》的“芝麻开门”口诀，还是江湖中“天王盖地虎，宝塔镇河妖“的江湖黑话，都是使用密码进行身份认证的基本形态。但随着密码使用场景越来越敏感，密码技术的自身安全性也不断受到挑战。特别是日新月异的今天，不断推陈出新的互联网服务都需要通过密码进行用户的身份认证，但是也随着网络安全的发展，密码这一传统身份认证方式已经难以得到可靠的认证保障，随之进化出各色新认证方式，其中就包括近几年风头正劲的无密码身份认证。
先来谈谈密码的问题。
常见只以密码作为身份认证凭证，当前面临各类安全挑战：弱口令暴力破解、口令数据库被拖库、密码重用被撞库、木马钓鱼定向攻击等。时至今日，密码问题依然是全世界范围重大网络安全事件最主要因素。
图1 Chrome 78开始已推出密码泄漏的检测功能
为了解决这些密码问题，人们通过不断加强密码复杂度、不同平台设置不同的密码等手段加强密码保护。但随着互联网服务不断推出，社交网络、电商购物、游戏娱乐、本地生活等，充斥着大量的个人信息资产，对于用户而言，记忆大量不同平台密码本身就不友好，这也促使用户变得懒惰、草率应付密码设定，使建立密码基础之上的安全建设摇摇欲坠。虽然随之出现了lastpass、1password此类密码管理应用，通过一个主密码来管理不同平台服务密码，虽解决了一部分问题，但自身服务安全性的不足也会带来更大的隐患。
图2 LastPass出现0day导致的密码泄漏风险
密码之所以出现上述种种困境，究其原因是因为密码身份认证凭证的中心化管理，当被他人获取密码后，对于云端服务来说皆可获得合法身份访问。后来也增加了一些多因素认证（Multi Factor Authentication，即MFA），但也存在一定的被拦截风险。
而无密码认证与密码认证的不同，主要就是借鉴零知识证明思想（Zero-Knowledge Proof，即ZKP，证明者prover能够在不向验证者verifier提供任何有用的信息的情况下，使验证者verifier相信某个论断是正确的），身份验证并非必须依赖身份凭证本身，而也可以通过数字签名确认认证结果，从而将认证方式与认证协议相分离。
目前，苹果、谷歌、微软三大科技巨头都宣布了支持无密码认证标准，未来移动智慧终端（手机、智能手表等）将成为互联网上的万能钥匙。这背后都有一个共同的身影：FIDO。（除FIDO外，国内也有IFAA、腾讯SOTER等类似解决方案，本文以FIDO为例进行说明）
图3 苹果、谷歌、微软宣布支持FIDO无密码认证标准
FIDO协议
3.1 FIDO简介
FIDO（即Fast IDentity Online，线上快速身份验证）是FIDO联盟发布的一套协议标准，其中包含以下三部分主要内容：
UAF（Universal Authentication Framework）：通用认证框架，为FIDO定义的一套统一身份认证框架，将认证方式与认证协议相分离，初期UAF为客户端SDK API，后FIDO2又提供WebAuthn的一套Web JS API更有利于部署。
U2F（Universal 2nd Factor）：通用第二因素认证标准，后正式命名为CTAP1，其作为传统密码的一种能力补充，提供基于认证器的第二种认证方式。
FIDO2：为FIDO 联盟和万维网联盟(W3C)于2018年共同发布的最新协议标准，其核心规范包括 WebAuthn（W3C Web Authentication，Web身份验证）、CTAP2（CTAP，客户端到认证器协议）两个部分，同时兼容原CTAP1（即U2F）协议内容。其中WebAuthn是一套用于访问公共密钥凭证的JS API，可视为FIDO2服务端与认证器部分的中心媒介；而CTAP为认证器访问客户端的定义的协议标准，主要为认证器提供API。
图4 FIDO2协议示意
3.2 FIDO的基本流程
无密码认证基于非对称加密，身份认证逻辑及认证凭证保存在用户本地的认证器，认证器在首次注入云端服务生成一对公私钥对，并将公钥发送给云端服务，用于账号身份的数字签名验签。具体如下图：
图5 FIDO构成示意
可见，用户身份校验主要依赖数字签名验签，服务端只存储用户身份的公钥，私钥与设备绑定，身份认证流程只在本地完成，即使服务端遭受攻击导致被拖库，也只会泄漏用户公钥，并不会像传统密码认证一样，导致身份认证凭证的泄漏。
那么来看看FIDO的基本流程，其最主要的就是注册与认证两个流程。
1.FIDO注册
图6 FIDO注册流程示意
FIDO的主要注册流程：
用户访问业务通过FIDO Client（webAuthn）触发FIDO注册请求；
业务服务端向FIDO Server透传注册请求，FIDO Server基于用户账号信息生成challenge返回给FIDO Client；
FIDO Client通过CTAP1/CTAP2与认证器通信，透传challenge信息；
认证器于TEE环境生成并存储用户公私钥对，并使用认证器的设备根密钥（私钥，由设备出厂预置）对用户公钥、challenge进行签名，并返回用户公钥及签名信息，由FIDO Client发送给FIDO Server；
FIDO Sever使用认证器的设备公钥对注册信息进行验签，验证通过后，存储用户公钥作为认证凭证，绑定用户关系；
返回业务服务器注册成功。
2. FIDO主要认证流程
图7 FIDO认证流程示意
FIDO的主要认证流程：
用户访问业务通过FIDO Client（webAuthn）发起身份认证需求；
业务服务端向FIDO Server透传认证请求及用户身份信息，FIDO Server基于用户身份信息生成challenge返回给FIDO Client；
FIDO Client透传challenge信息给到认证器，触发本地身份认证；
认证器选择认证方式（人脸、指纹、NFC、硬件Ukey等）进行用户本地身份认证；
通过用户认证后，使用user privkey对challenge等信息进行签名，返回签名信息；
发送用户签名的认证信息给到FIDO Server，FIDO Server使用注册时存储的用户公钥进行验签，确认用户身份信息；
确认用户身份后，向业务服务器确认用户身份信息认证成功。
通过上述的流程可见，FIDO的无密码认证与密码认证的最大不同，就是认证凭证不再集中存储于服务端。基于非对称加密，用户私钥保存于认证器本地，认证器通过本地认证（生物认证：人脸、指纹、声纹、虹膜；硬件认证：NFC、蓝牙、芯片等）完成身份验证后，对服务端挑战值进行签名，服务端仅保留用户公钥用于认证消息验签，从而完成云端服务身份认证过程。
整个流程的保护要点就是设备根密钥、认证器认证信息、用户私钥，这些信息往往存储于终端设备的TEE环境，来保证其密钥的安全。
另外，FIDO并非完全颠覆现在的密码认证体系，除当前CTAP2协议外，保留了CTAP1（U2F）在现有密码认证上做加法 ，作为第二因素校验，使业务向无密码认证可以平滑过渡。这与常见的短信OTP作为第二因素校验不同，短信OTP的本质还是服务端完成关键凭证认证，其无法有效避免钓鱼、社工等定向攻击导致的泄漏（近些年频发的电信诈骗问题可见一斑），所以CTAP1具备更明显的优势。
以FIDO为代表的无密码认证大幅提升用户体验，一个认证器可以跨多平台使用，免去用户记录大量平台密码的麻烦，且在需要频繁认证的业务场景下，避免频繁输入各类口令的麻烦。同时也极大的提升密码攻击的对抗能力，即使服务端发生账号泄漏事故，或因用户的安全意识不足，遭遇密码暴力破解、钓鱼攻击以及社会工程促使的主动泄漏等问题，攻击者也无法通过获取的密码用于登陆用户账号，不会因用户账号凭证泄漏造成更大的危害。
但这并非代表着身份认证业务的绝对安全，其只能在终端设备安全、密钥安全条件基础上，保证认证结果的准确性。而面对认证通过后的会话窃取，依然无能为力。另外，面临认证器设备丢失问题，有效可靠的更换流程机制也极为重要。所以面对具体业务场景，需要针对性进行功能安全设计，才能更好地为业务保驾护航。
参考文章：
[1] https://fidoalliance.org/
[2] Web Authentication:An API for accessing Public Key Credentials Level 2,https://www.w3.org/TR/webauthn/
[3] FIDO 技术原理简要剖析,https://www.doczhi.com/p-862544.html