飞书是否把 passkey 当成另一种密码使用，这是一个好实践吗

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 49 days ago, the information mentioned may be changed or developed.

大部人网站，可以直接选择 passkey 登录，然后调用密码管理工具等进行认证：

https://i.imgur.com/8VA98OY.png

https://i.imgur.com/iz4P7K3.png

但是飞书并没有，需要先输入账号，然后选择是否使用 passkey：

https://i.imgur.com/hIlFzLj.png

https://i.imgur.com/4Pgt7BO.png

这是不是把 passkey 当成另一种密码来用了，感觉使用体验还不如普通的账号+密码，远不如别的服务上 passkey 的体验丝滑

飞书的账号+密码：设备认证一次解锁用户名，自动解锁密码

别的服务的 passkey：设备认证一次解锁 passkey

飞书的 passkey：设备认证一次解锁用户名，再认证一次解锁 passkey

Passkey

密码

体验

31 replies • 2026-03-25 22:31:49 +08:00

Hack3rHan

Mar 24

也不是都支持直接 Passkey 的，Google 和 Microsoft 登录就需要用户名。感觉输入用户名后弹 Passkey 逻辑上也没有什么问题。

deplives

Mar 24

阿里的才绝，通过 passkey 后还得经过 MFA 最尼玛离谱

Muniesa

Mar 24 via Android

cloudflare 把 passkey 当两步验证

FlashEcho

Mar 24

@Hack3rHan #1 还真是，看来像苹果和 github 这种优秀实践少，原来是大部分网站和飞书一样

lizhenda

Mar 24

Google 和 Microsoft 就是这样呀，没啥问题其实

orFish

Mar 24

@deplives aliyun 的可以直接登录了啊，不用在 mfa

deplives

Mar 24

@orFish

thevita

Mar 24

aliyun 和 github 类似的, Sign in 和 Two-Factor 使用什么都是可以单独设置的，以及可以设置什么时候需要 2FA ，检查下你的安全设置先

unused

Mar 24

看起来是 discoverable 和 non-discoverable credential 的区别，狭义上 non-discoverable 不叫 passkey

lsearsea

Mar 24 via Android

用下来，单独能 passkey 登录的才是少数

Opportunity

Mar 24

GitHub 上也是分开的啊

Passkeys can be used for sign-in as a simple and secure alternative to your password and two-factor credentials.

Security keys are webauthn credentials that can only be used as a second factor of authentication.

zxjxzj9

Mar 24

感觉 passkey 代替密码才是一般操作(有了用户名之后可以选择 passkey 或者密码)

traffic

Mar 24

腾讯云的才绝，用 passkey 登录后还得验证 TOTP

zsh2517

Mar 24

确实存在三种规范

1. 不需要输入用户名（或者邮箱）的：discoverable credential （之前也叫 resident key ）
2. 需要输入的用户名不需要密码的：non-discoverable credential
3. 需要输入用户名，再输入密码，再验证密钥，作为 MFA ，好像叫做 U2F 来着

1 、2 都是主流用法，3 是比较老的方案。

原理忘了，大概印象是，第一种要往设备上存东西，所以硬件密钥比如 yubikey 支持的数量有限（几十或者一百个）。non-dis 和 U2F 不需要，所以可以几乎无限。建议找 AI 详细问一下，大概要结合三种认证的具体流程来分析

zsh2517

Mar 24

@zsh2517 这里只是说这三种用法都是有规范定义的，至于为什么这么设计我也不清楚。

我个人不觉得硬件密钥数量是主要考虑因素

盲猜可能会有兼容性/隐私/安全性之类的原因

Tubbs

Mar 24

@deplives 太专业了，还发了个动图哈哈哈

ZRS

Mar 24 via iPhone

@deplives 请教一下这动图咋整的

940i3s34v4F1HW41

PRO

Mar 24

passkey 毕竟不是国产自研，搭配一层国研的 mfa 还是可以理解的吧

wolonggl

Mar 24

passkey 可以保存在第三方软件中，比如 bitward ，泄漏 passkey 和泄漏用户和密码都一样，感觉安全性没有提升；

nelloshaw7713

Mar 24

passkey 目前用的还挺多的，个人感觉比账户密码好用挺多的。

e3c78a97e0f8

Mar 24

@wolonggl passkey 和密码的安全不一样。你举得例子里的确是一样的问题，但是还有很多其他情况，密码远不如 passkey

（以下是 AI 生成）

无法被钓鱼：Passkey 绑定了特定域名，钓鱼网站没法欺骗你提供登录信息

私钥不出库：数据库泄露的只是公钥，黑客没有你的本地私钥，依然无法登录。

不存在全网通杀：密码泄露会导致“撞库”，但 Passkey 为每个网站生成唯一密钥对，一个站点的泄露绝不威胁另一个站点。

抗暴力破解：密码可以被穷举，但基于非对称加密（ RSA/ECC ）的 Passkey 理论上无法通过计算破解。

无传输风险：登录时服务器不校验密钥原文，只校验签名，链路截获对 Passkey 无效。

msg7086

Mar 25

@zsh2517 #14
对的，第一种是作为身份存储，所以是每个网站每个账户要单独生成秘钥，储存数量有限。第二种只做验证，所以是所有网站所有账号都共享一个秘钥（但无法通过设备秘钥关联起不同账号）。

mangoDB

Mar 25 via iPhone

我记得 onlyfans 也是先输入用户名然后才能调用 passkey

Hack3rHan

Mar 25

@msg7086 第二种其实也是每个网站一个，不会共享一对密钥，如果共享可以导致轻易的被跨平台追踪，影响隐私安全，这个是设计规范考虑到的问题。

likelylee

Mar 25

@traffic @deplives 不讨论是否需要用户名，单纯从 passkey 的实现机制上来看，严格来说不是 MFA 或者 2FA ，而是 muulti-step authentication ，这个在部分合规场景下是被要求禁止的，这也就是为什么很多大型机构面对复杂合规的时候会尽可能的按照没风险的方案来执行。
但是，passkey 作为 something you hava ，和 OTP 联用的时候也不是 MFA ，但如果和密码联用虽然是传统意义的 MFA ，只是就没有了 passkey 的优势了。
所以，说白了这些大机构把 passkey 作为 MFA 的一环都是合规考虑，但是并没有真正理解 passkey ，也没有真正理解合规要求。因为我就是做 passkey 认证以及大机构合规的...

msg7086

Mar 25

@Hack3rHan
如果你说的是临时秘钥，那是每个账号一个，不是每个网站一个。
我说的共享一个秘钥是说只有一个主秘钥，所以不会有储存数量限制。