我们可以用比特币的想法来摆脱传统的密码方案吗？ （用户名、哈希）

Question

我考虑了传统的密码哈希： https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846

但是，比特币有一种方法可以让人们使用人类可读的种子短语作为其“帐户”的恢复秘密（BIP-39）： https://en.bitcoin.it/wiki/Seed_phrase

他们可以使用列表中的 12-24 个随机英语单词，因此这组单词具有很高的熵。 这有助于以传统方式在纸上备份重要机密，而不是备份很长的加密密钥。

从高熵种子中，他们以编程方式导出 ECDSA 密钥对或密钥树，并使用公钥作为标识符和私钥来签署可以使用公钥验证的挑战。

我们是否可以使用类似的系统来摆脱传统密码认证的一些问题？ （例如发送纯文本密码并在服务器上集中对计算机进行哈希处理，需要大量云成本，使用个人可识别数据作为用户名，不知道服务器哈希是否正确或他们如何处理我们的个人数据）

附带说明：网络钓鱼机密问题可以通过自动填充或小心、不频繁地手动使用机密来解决。

想法：

• 生成 25 个随机 Base32 令牌（26 个字母 + 10 个数字 - I、O、1、0）作为人类可读的密码，可以存储在通行证管理器或便利贴上或任何地方（12-24 个单词是一个）很多字符，也可以通过减少字符数和视觉分隔符来实现可读性）
• 我们可以使用 pbkdf2 将客户端上的密码哈希为种子，然后使用该种子生成 ECDSA 密钥对，就像使用 BIP-32 一样，而不是在服务器上对密码进行哈希处理： https://en.bitcoin.it/wiki/BIP_0032
• 公钥将作为一种用户名（匿名），存储在服务器上而不是密码哈希
• 如果泄露，暴力攻击必须重新创建计算机密集型密码哈希过程来攻击私钥，就像我们在服务器上存储密码哈希一样
• 通过身份验证，客户端将进行哈希处理，提供公钥并使用私钥对一些随机服务器挑战进行签名，服务器将验证公钥的存在并找到相应的内部用户 ID 并使用公钥验证签名钥匙

这似乎是对传统密码管理的帕累托改进：

• 秘密不会传播
• 服务器负载最小，因为 CPU 密集型密码哈希发生在客户端
• 如果服务器上的公钥泄漏，则类似于密码哈希泄漏：暴力攻击必须执行密集的 pbkdf2 哈希过程（这就是为什么我会使用密码哈希来获取种子）
• 没有个人用户名
• 透明密码哈希

它甚至可以与传统方案一起使用，例如用户名/电子邮件/电话号码+密码。 初始熵通常不是那么大，加盐并没有真正的意义，因此可以使用一种全局盐（胡椒）。然而，如果我们不单独对每个条目加盐，我们会失去什么，但我们会通过用户名获胜，因为它没有在受感染的服务器上存储纯文本，因此当在客户端上对用户名+密码进行密码散列时，熵实际上更高。

至于实现，我考虑了以下库： https://github.com/bitcoinjs/bip32/blob/master/src/bip32.js

但是 Web 加密 API 中可能有本地方法可以执行相同的操作。

Answer 1

有一种使用最近标准化的 ECDSA 和/或 Ed25519 密钥对的现有方法，称为 passkeys。它们使用与 FIDO2 安全密钥（例如 YubiKeys）相同的技术，但它们以可以跨机器传输的方式存储。它们不是用种子生成的，而是伪随机生成的，并存储在某种加密存储中（可能以正常方式受密码保护）。它们通常可以在大多数支持 FIDO2 的网站上使用，只需很少的额外工作。

正如您所提到的，优点是服务器只有一个公钥，并且这些密钥已经被认为是众所周知的安全模型的一部分。由于它们是使用 CSPRNG 生成的，假设 CSPRNG 是安全的，那么它们在功能上就不可能被猜测。此外，它们对于每个站点都是唯一的，并且不能与其他密钥关联，因此站点 A 无法仅根据凭据将其用户与站点 B 关联起来。

许多网站仍会使用用户名，因为在与其他用户交互或获得支持时，为用户提供标识符很方便。由每个站点决定。

请注意，对于 SSH，OpenSSH 已经提供基于 FIDO2 的安全密钥作为特殊密钥类型，因此用户可以使用 ECDSA 或 Ed25519 密钥（其中存储支持作为安全密钥），并且 SSH 密钥已经受益于许多与万能钥匙。