从输入密码到签名消息：认证逻辑的根本转变

📚 作者：Henry 🧱 系列：《Web2 到 Web3：登录与身份验证机制全面进化》 · 第 2 篇 👨‍💻 受众：Web2 & Web3 开发者 / 区块链学习者 👉 系列持续更新中，建议收藏专栏或关注作者

Web2：密码凭证验证机制回顾

在 Web2 登录中，用户身份的认证依赖服务端验证用户输入的密钥（password）是否与数据库中哈希后的记录匹配：

四个角色：用户（User）、客户端（Client）、服务器（Server，隐含）、数据库（Database）

流程描述

• 用户输入凭证
  • 用户在客户端界面上输入用户名和密码
  • 这一步是典型的「共享凭证」输入，服务端也需要拥有密码的哈希才能比对
• 客户端提交凭证
  • 客户端将用户输入提交给后端认证接口（通常是 REST API）
  • 一般使用 HTTPS 保障传输安全，但凭证依然处于“明文可见”状态
• 服务端查询数据库
  • 后端服务器接收到凭证后，从数据库中读取用户账号对应的密码哈希
  • 使用 bcrypt、scrypt 等算法对输入进行哈希，然后进行比对
• 返回登录结果
  • 若匹配成功，返回成功响应，并可能设置 Cookie / JWT 等身份令牌
  • 否则返回错误信息，提示用户验证失败

🔍 安全隐患

• 密码在传输和存储过程中需要大量额外加密与隔离机制保护
• 用户一旦在钓鱼页面输入密码，服务端无从得知其真实性
• 数据库泄露将导致大规模用户身份暴露（即便密码已哈希）

Web3：签名即身份的认证范式

在 Web3 中，用户从不提交凭证。服务端也不“知道”用户是谁，而是通过验证“这段消息是否由该地址私钥签名”来确认身份。

换句话说：用户不是提供密码，而是证明“我能控制这个地址”

🔐 核心流程

• 用户进入地址
  • 用户通过钱包连接，将钱包地址（如 0x...）传递给前端。
• 客户端向服务端请求登录消息（含 nonce）
  • 为防止签名重放，后端会生成带时间戳、随机数的消息模板。
• 用户使用钱包对消息进行签名
  • 钱包弹出签名确认窗口，用户确认后私钥完成签名。
• 客户端返回签名和地址
  • 前端将签名结果及用户地址提交给后端。
• 服务端验证签名
  • 使用 recoverAddress 等方法验证签名是否能还原出用户地

✅ 消息模版的生成与签名，始终遵循：由后端创建消息模版，前端只负责展示并发起签名

在整个签名登录过程中，前端与后端有明确的分工：

// 前端通过接口请求，获取到后端维护好的消息模板；前端根据消息模版的形式，构建好待签名的消息，如：
const message = `
${domain} wants...