从 Cookie 到 SIWE：互联网身份验证的“去中心化”进化史

01. 洪荒时代：明文与加密的猫鼠游戏 (1994 - Cookie/Session)

互联网的身份验证史，始于 1994 年。那是一个由 Cookie 和 Session 统治的时代，也是安全隐患最猖獗的时期。

在那个阶段，用户行为极其朴素：输入账号密码，服务器验证通过。然而，这种简单的交互在黑客眼中却是巨大的机会。早期的 HTTP 协议如同在互联网上“裸奔”，黑客只需潜伏在公共 Wi-Fi 环境下，就能通过嗅探轻松截获明文传输的账号密码，直接完成身份窃取。

为了应对这一危机，HTTPS 应运而生。 加密通道的建立让请求文本变成了一堆乱码，但这引发了黑客界的第二次战术升级：如果无法破解内容，那我是否可以直接录制并“重放”你的加密请求（Replay Attack）？

所幸，TLS 机制筑起了第二道防线。 由于 HTTPS 在底层建立连接时依赖临时密钥机制，黑客截获的历史请求在新的连接上下文中会因密钥不匹配而失效。虽然技术层面的攻防暂时告一段落，但“账号密码”这一模式本身带来的密码泛滥（Password Fatigue） 和 撞库风险，却成为了下一个时代的阿喀琉斯之踵——当一个网站泄露，用户所有的网站往往随之遭殃。

02. 联邦时代：为了便捷，我们出让了主权 (2012 - OAuth 2.0)

既然管理密码如此痛苦，行业开始寻找新的出路。2012 年，RFC 6749 标准确立，OAuth 2.0 时代正式降临。

有趣的是，OAuth 最初的设计初衷并非为了“登录”，而是为了解决服务间的资源授权（例如授权某在线文档服务读写你 Google Drive 中的文件）。但开发者们很快发现，这种生成临时 Token 的机制极其适合用来做身份认证。于是，“使用 Google/Apple 登录”成为了互联网的标配。

这确实是一场体验革命： 用户不再需要记忆繁琐的密码，登录变得丝般顺滑。然而，这种便捷并非没有代价。

我们不知不觉中走入了“数字封建主义”的陷阱。在这个模型下，账号的所有权并不在你手中，而在互联网巨头手中。 一旦触发平台红线导致封号，或者巨头服务宕机，你将瞬间失去登录所有关联应用的能力。这种对中心化权威的过度依赖，为 Web3 时代的到来埋下了伏笔。

03. 主权时代：以密码学重构信任 (2021 - SIWE & Web3)

2021 年，SIWE (Sign-In with Ethereum) 标准的出现，标志着 Web3 签名时代的开启。这一次，我们不再向巨头申请“通行证”，而是直接出示“私钥”作为身份的数学证明。

其交互流程看似回到了“手机验证码”的逻辑，但底层却发生了质变：

挑战： 网站向用户的钱包发送一段包含随机码（Nonce）的签名请求。
应答： 钱包（如 MetaMask）使用用户的私钥，通过算法对这段文本进行签名。
验证： 网站拿着签名文本，验证其是否与你的公钥匹配。

这里有两个至关重要的技术细节，决定了这套体系的安全性与可行性。

第一是 Nonce（随机数）的防御机制。

既然签名是静态的，如果没有变量，黑客截获签名后岂不是可以无限伪装成用户？

Nonce 的引入正是为了解决这个问题。它不仅包含随机码，还绑定了域名信息和时效性（例如 5 分钟后失效）。这意味着，即便黑客拦截了你的签名，这个签名也只能在极短的时间窗口和特定的域名下生效，极大地压缩了作恶空间。

第二是算法的选择：为何是 ECRecover 而非 RSA？

在验证环节，核心逻辑是 算法(私钥, Nonce) = 签名，然后服务端通过 算法(签名) = 公钥 来验明正身。这就引出了一个纯技术问题：为什么 Web3 普遍采用 ECRecover（椭圆曲线恢复算法），而不是传统的 RSA？

虽然 RSA 也能实现 RSA(私钥, Nonce) = 加密文本 的效果，但在同等安全级别下，RSA 的效率极其低下。要达到这一安全标准，RSA 需要至少 3072 位的密钥长度，这导致加解密耗时增加，且生成的文本体积庞大。

相比之下，ECRecover 仅需 256 位密钥即可达到同等安全性。在海量并发的互联网应用中，这种**“短密钥、高效率”**的特性，使其成为了大规模去中心化验证的唯一之选。

结语

从 HTTP 的明文传输，到 OAuth 的巨头背书，再到 SIWE 的密码学自证，身份验证的进化史，本质上是人类在安全、便捷与主权三角不可能中的一次次权衡与突围。

值得注意的是，虽然 Web3 改变了“入门”的方式，但目前的架构并没有完全抛弃传统——在验证通过后，大多数应用依然会回落到使用 Cookie 或 Header JWT 来维持会话。但这跨出的第一步，已经足以让我们重新审视：“我是谁”这个问题，究竟该由谁来定义？