当 Chrome 于本月初推送 108 版本到大家手中时，通行密钥（Passkey）就已经在主流的生态系统中准备就绪了。作为一项由 FIDO 联盟发起和推广的无密码登录标准， 通行密钥（Passkey）虽然早在今年 6 月份的时候就在 WWDC 上亮相并走入了大家的视野，不过「无密码的未来」看起来一直雷声大雨点小——好像除了系统支持就没有具体实例支持通行密钥这个功能。
其实并不然，所以本文将从通行密钥是什么出发，一起来看看通行密钥的生态如何以及我们可以怎么设置通行密钥。
通行密钥如何「取代」密码虽然早前少数派有专门的文章介绍其工作原理，不过这里还是要简单介绍一下通行密钥是干什么以及是怎么做到的。
简单来说，通行密钥主想要实现的，是在原本的「用户名-密码」安全体系外，寻找一种更为简单、直接，但同样具备安全性的用户身份验证方式。比如你正在使用一台设置了面容 ID 的 iPhone，那通过面容 ID 解锁这台 iPhone 即可证明目前是你本人正在操作——而这要比输入登录信息、甚至自动填充登录信息都要快速无感。
这个替代验证手段的思路具体到原理，从某种程度上来说则是真的「干掉了密码」。通行密钥将以往需要加密储存在服务器端的登录信息，替换为非对称加密技术中的口令。和包含用户名、密码的传统凭证数据不同，在非对称加密技术中，注册通行密钥的设备会成一段「公钥」和「私钥」交给提供注册服务的服务器。
我们可以把公钥类比于带「防盗」锁的传统信箱，把私钥类比于信箱的锁的钥匙。邮递员投递的信件就是我们要加密的信息，通过投递到信箱中加密起来，然后也只有信箱的主人才有钥匙能够打开信箱读取信件的内容。如果一个人手上没有钥匙，那就需要用暴力开防盗锁，整个过程不仅耗时耗力，最后也往往没办法打开那把防盗锁。与之对应的，如果某些内容被公钥加密了，则该内容能且仅能被私钥解密。
非对称加密的可靠性正来源于此——若无私钥，在有限的算力和有限的时间内我们一般无法完成极大整数的因数分解；如果加密内容能被解密，则说明对方拥有私钥。
所以只要服务器用公钥加密一段认证信息，用户设备上的私钥钥可以解密这段认证信息，那么就可以证明我是「我」了，这也是通行密钥的实现基础，而通过这一个间接匹配就完成了密码认证。整个过程既不用劳神费力的敲入具体的密码、也不需要让密码离开本地设备，更能避免因为服务器受攻击而导致密码泄露，降低传输风险。
图｜《不用密码但不能代替密码：通行密钥如何让登录这件事更简单？》
不过用户保存在本地的私钥也需要有安全保障，不然恶意程序随意访问就会破坏这样的间接认证机制。所以在使用通行密钥时往往都会配合用户设备上的生物识别系统进一步加密保存在本地的「私钥」，比如 iDevice 设备上的 TouchID/FaceID、Android 设备上的指纹识别、Windows Hello，甚至是简单的 PIN 认证都可以进一步增强访问私钥时的安全性，而这也是通行密钥绕不过的重要组成部分。
图｜《不用密码但不能代替密码：通行密钥如何让登录这件事更简单？》
哪些平台和服务支持通行密钥通行密钥背后的技术基础是由 W3C 在 2019 年就纳入正式标准的 WebAuthn 认证，在早期这个 API 只能通过实体密钥使用。但今年 Apple、Microsoft 以及 Google 的大力推进下手边的电脑、平板或是手机也可以通过通行密钥化身为实体密钥了。据我统计以下的平台均支持通行密钥：
- Apple：iOS 16、iPadOS 16、macOS Ventura 与 tvOS 16 以上均支持，支持 iCloud 钥匙串同步且支持通过 AirDrop 分享
- Google：Chrome 108 版本以上、Google Play 服务（Google 自动填充框架）为最新版，支持在 Android 与 Android、Android 与特定版本 Chrome 之间同步
