LNURL-auth 登录签名：一个种子如何在不同网站派生不同身份

没有密码框的登录：一把域名专属钥匙

LNURL-auth 是闪电钱包生态里的”用钱包登录”协议（LUD-04 规范）。网站展示一个带 tag=login 的 LNURL 二维码，你的钱包扫码后不对任何地址付款、不广播任何交易，它做的唯一一件事是：用一个从种子派生的专用私钥，对网站给出的一串 32 字节随机数做 secp256k1 签名，把公钥和签名发回去。网站用收到的公钥验签通过，就承认”你”存在，把你登记为一个账户或会话。全程零链上动作、零资金流动，也不存在服务器能拿走的密码——你交出的是一个针对一次性随机数的签名，签名本身无法复用，服务器也推不出你的私钥。

关键机制拆解

第一，这把钥匙不是你的节点身份公钥。规范明确 node key 不能拿来当登录凭据，否则每次登录都等于向网站广播闪电网络身份，跨站可关联。实际使用的是 linkingKey：从钱包种子出发，按 BIP32 路径 m/138’ 派生出一个哈希密钥，再对”网站的完整域名”做 HMAC，把结果前 16 字节折成四个数字当作路径后缀，最终得到 m/138’/long1/long2/long3/long4 形式的域名专属密钥。同一钱包在 example.com 和 shop.example.com 上是两个互不相干的账户身份，网站之间无法凭公钥串你的行为——前提是这个域名进过派生，而这正是要理解的第一代价。

第二，域名即账户。因为派生把域名当材料，网站如果把登录服务从 auth.site.com 迁到 login.site.com，同一批用户会派生出全新的一把钥匙，老账户全部对不上号。规范专门警告服务端要终身固定认证子域。对用户的镜像含义是：钓鱼者用仿冒域名做登录页时，你签出来的是一把全新账户的钥匙——不会丢币，但你可能误以为”登录成功了=身份被认可”，从而在假站点上继续填别的东西。

第三，k1 是防重放的锚。网站每次登录请求生成新的 32 字节随机数，并（按规范建议）维护一个未使用 k1 的缓存，只对缓存里的 k1 接受签名，验证成功立即作废。攻击者截获一次登录流量，无法用同一签名换第二次会话。钱包端还应把 action 参数（register、login、link、auth 四档）翻译成人话显示在确认弹窗里，让你知道这次签名的用途。

安全边界与故障场景

它防住了什么：钓鱼站拿不走密码（没有密码可偷）；数据库拖库拿不走可复用凭据（服务器只存公钥）；中间人重放登录流量（k1 单次有效）。它防不住什么：如果钱包实现把 linkingKey 派生错进别的用途，账户体系崩塌；如果用户不看弹窗域名就确认，签名照样发给假站——验签正确但身份关系错误；服务器端如果不设 k1 缓存、来者不拒，重放防护形同虚设。

故障侧最常见两类。其一，换设备恢复钱包后”登录不上了”：只要种子相同、LUD-05 派生实现一致，密钥必然一致，问题多半出在恢复钱包没有启用 auth 功能或站点改了子域；拿旧设备对新设备同一站点各登一次即可定位是哪侧的问题。其二，报错 k1 mismatch 或类似字样：多为会话超时（网站等签名请求的窗口过了），重新刷新二维码再扫即可，反复失败则检查钱包内置浏览器对 callback 请求的拦截设置。

和相邻技术的分工也划一下：这与 OpenID Connect、WebAuthn 解决同一问题（免密码认证），但信任根是你钱包的种子而不是平台密钥服务；与”给消息签名证明地址所有权”（BIP322 一类）也不同——auth 签的是登录挑战，派生自种子的域名密钥不指向任何链上余额。

风险提示：本文为协议机制科普，不构成投资建议。任何要求你”先扫个码验证身份”的页面都值得先看域名再动手。