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