能否借鉴比特币思路替代传统用户名密码哈希认证方案？

背景与思路起源 #

我曾研究过传统密码哈希方案，不过比特币采用的BIP-39方案让用户使用人类可读的助记词作为账户恢复密钥——用户从固定列表中选取12-24个随机英文单词，这类词集具备高熵值，相比备份超长加密密钥，更便于用户通过纸质方式备份重要密钥。基于该高熵种子，还可程序化生成ECDSA密钥对或密钥树，将公钥作为标识，私钥用于签署可通过公钥验证的挑战信息。

由此我想到：能否采用类似方案解决传统密码认证的诸多问题？例如明文密码传输、服务器端哈希运算占用大量算力与云成本、使用个人可识别数据作为用户名、无法确认服务器哈希操作是否合规及数据处理方式等。

补充说明：钓鱼窃取密钥的问题可通过自动填充或谨慎、低频次手动使用密钥来缓解。

具体构想 #

• 生成25个随机base32令牌（包含26个字母+10个数字，剔除I、O、1、0）作为人类可读密码，可存储在密码管理器、便签纸或任意位置（12-24个单词字符过多，减少字符数并添加视觉分隔符也可提升可读性）；
• 不在服务器端进行密码哈希，而是在客户端通过pbkdf2对密码进行哈希运算生成种子，再参照BIP-32方案生成ECDSA密钥对；
• 将公钥作为匿名用户名存储在服务器，替代密码哈希值；
• 若公钥泄露，攻击者需重新执行高算力密码哈希运算才能破解私钥，这与服务器存储密码哈希值泄露后的攻击难度相当；
• 认证时，客户端完成哈希运算，提供公钥并使用私钥签署服务器发送的随机挑战信息；服务器验证公钥是否存在，找到对应内部用户ID并通过公钥验证签名。

相比传统方案的帕累托改进 #

• 密钥无需传输；
• 服务器负载极低，高算力密码哈希运算在客户端完成；
• 若服务器公钥泄露，攻击者需执行高强度pbkdf2哈希运算，这也是选择通过密码哈希生成种子的原因；
• 无需使用个人化用户名；
• 密码哈希过程透明。

与传统认证方案的结合 #

该方案可与“用户名/邮箱/手机号+密码”的传统方案结合使用。通常初始熵值并不高，单独加盐意义不大，因此可使用全局盐（pepper）。不过，虽失去了为每个条目单独加盐的优势，但由于用户名不会以明文形式存储在被攻陷的服务器中，在客户端对用户名+密码进行哈希运算时，实际熵值反而更高。

实现思路 #

可使用bip32相关库实现密钥生成逻辑，另外Web Crypto API中也可能存在原生方法可实现相同功能。

内容的提问来源于stack exchange，提问作者prime