哈希 vs 加密：常见误区与正确用法

1. 哈希与加密的本质区别

这两个概念经常被混淆，但它们在安全属性上是完全对立的。让我们用一个简单的类比：

加密：可逆的密钥保护

加密像是一把安全门锁。你用钥匙（密钥）锁上，收件人用相同或配对的钥匙解锁。

• 明文 + 密钥 → 加密 → 密文
• 密文 + 密钥 → 解密 → 原始明文
• 例子：AES、RSA、ChaCha20
• 应用：通信保密、文件加密、数据库字段加密

关键特性： 可逆、确定性（相同输入+密钥 = 相同输出）、需要密钥管理。

哈希：不可逆的指纹

哈希像是一个指纹识别系统。输入信息被转换成一个固定长度的"指纹"，无法从指纹还原出原始信息。

• 输入数据 → 哈希 → 哈希值（指纹）
• 无法从哈希值逆向得到原始数据
• 例子：SHA-256、SHA-3、MD5（已过时）
• 应用：密码存储、文件完整性检查、区块链、数字签名

关键特性： 不可逆、确定性、快速、碰撞概率极低。

对比表

2. 单向函数：为什么哈希无法逆向

单向函数的数学性质

哈希函数是一个单向函数（One-way Function），具有以下性质：

• 正向容易 — 给定输入 X，计算 H(X) 很快（纳秒级）
• 逆向困难 — 给定哈希值 H，找到任何输入 X 使得 H(X) 等于给定值是不可行的
• 碰撞稀有 — 找到两个不同输入产生相同哈希（碰撞）极其困难

为什么不可逆？因为哈希涉及信息损失。从 512 位输入压缩到 256 位输出，本质上丢弃了一半的信息。即使尝试所有可能的输入，也无法确定哪个产生了特定的哈希。

实际例子：SHA-256

SHA-256 哈希函数如下：

即使你看到哈希值 `5e884898...`，也不可能通过逆向计算还原出 "password"。唯一的方法是尝试所有可能的输入，看是否能匹配这个哈希。对于强密码，这需要数十亿年。

为什么加密不适合密码存储

如果用加密存储密码：

相比哈希存储：

3. 密码存储：为什么必须哈希不能加密

从零开始理解密码验证流程

用户注册时，系统需要存储密码以供后续登录验证。但如何安全地存储是核心问题。

方案 1：明文存储（灾难）

最不安全。数据库一泄露，所有密码都暴露。现实中曾有大量网站这样做，结果造成巨大安全事故。

方案 2：用加密存储（错误）

注册：密文 = AES_Encrypt("my_password", serverKey)

登录：接收用户输入，加密后与数据库密文比较。

问题：serverKey 必须存在服务器上。如果服务器被攻破或有内部人员作恶，获得密钥即可解密所有密码。

方案 3：用快速哈希（不够好）

注册：存储 hash = SHA-256("my_password")

登录：哈希用户输入，与存储的哈希比较。

改进：只有知道原密码才能验证成功（因为哈希无法逆向）。

问题：SHA-256 太快（纳秒级）。黑客可用暴力破解尝试数十亿个密码，在短时间内找到匹配。常见密码（如 "123456"、"password"）有预计算的哈希值（彩虹表），查表即可。

方案 4：用慢哈希 + 盐值（推荐）

注册：

登录：

优势：

• bcrypt 很慢（cost=12 约 100ms），降低暴力破解速度
• 随机盐值确保相同密码产生不同哈希，彩虹表失效
• 即使密码被猜中，验证速度也只是 100ms，用户几乎不感觉

4. 盐值与彩虹表攻击

彩虹表：预计算哈希表

彩虹表是攻击者预先计算的哈希表。它包含常见密码及其哈希值：

黑客从泄露的数据库中取出哈希，只需查表就能迅速找到对应密码。预计算表通常几个 GB，包含常见的数十亿个密码，查询极快。

盐值的防御原理

盐值（Salt）是在哈希前混入的随机数据。关键是每个用户使用不同的盐：

即使两个用户密码相同，盐值不同，最终哈希也完全不同。彩虹表失效，因为表中没有考虑这么多种盐的组合。

盐值的最佳实践

• 长度 — 至少 16 字节（128 比特）
• 随机性 — 用密码学安全的随机生成器
• 唯一性 — 每个密码都应使用不同的盐
• 存储 — 盐可明文存储（与哈希一起），它的作用是增加彩虹表的规模

好消息：bcrypt 和 argon2 都自动处理盐值生成和存储。开发者只需调用函数，不用手动管理。

5. bcrypt 和 argon2：慢哈希的力量

为什么慢哈希更安全？

快速哈希（SHA-256）设计用来哈希大量数据，速度是目标。但对密码存储，快就成了弱点——黑客可快速尝试数十亿个猜测。

慢哈希故意设计得慢：每次计算需要 100ms～1s。这对真实用户几乎无感（只登录一次），但对黑客破坏性极强：尝试 1 亿个密码需要 3000 年。

bcrypt：业界标准（25 年）

bcrypt 由 Niels Provos 和 David Mazières 在 1999 年设计，基于 Blowfish 加密算法。至今仍是最广泛使用的密码哈希方案。

关键参数：Cost（工作因子）

• Cost = 10 → ~10ms
• Cost = 12 → ~100ms
• Cost = 14 → ~1s
• 每增加 1，时间翻倍

推荐： 新应用使用 Cost = 12。如果需要额外安全，随时可升至 14（已有哈希不需重算）。

argon2：新一代标准（2015）

argon2 在 2015 年赢得 Password Hashing Competition。相比 bcrypt，它更灵活、参数更多、抗 GPU 攻击更强。

优势：

• 内存硬度（Memory-hard）— 不仅吃 CPU，也吃内存，更难被 GPU 加速
• 三种变体 — Argon2i（抗 GPU）、Argon2d（快速）、Argon2id（混合）
• 参数灵活 — 可独立调整时间、内存、并行度

推荐配置（2026）：

bcrypt vs argon2：选择建议

• bcrypt — 成熟、库支持好、足够安全。适合大多数应用。
• argon2 — 更新、参数丰富、抗硬件加速更强。适合超高安全需求（银行、军事）。

6. HMAC：消息认证与完整性校验

问题：纯哈希无法验证来源

假设服务器发送一条消息及其 SHA-256 哈希：

问题：中间人可以同时修改消息和哈希。

HMAC 的解决方案

HMAC（Hash-based Message Authentication Code）使用密钥和哈希函数组合，确保来源真实且内容未被篡改。

关键：攻击者没有 secret_key，无法计算正确的 HMAC。即使修改消息，新的 HMAC 也是错的。

HMAC 的应用场景

• API 签名 — AWS、Stripe 等 API 都用 HMAC 签名请求
• Cookie 防篡改 — web 框架用 HMAC 保护 session 数据
• 日志完整性 — 确保日志在传输和存储中未被修改
• 消息队列 — RabbitMQ、Kafka 等用 HMAC 验证消息真实性

HMAC vs 数字签名

两者都能验证来源和完整性，但不同：

• HMAC — 对称（双方共享密钥），适合内部系统通信
• 数字签名 — 非对称（私钥签名，公钥验证），适合公开验证

7. SHA-256 vs SHA-3：算法演进

SHA-256（SHA-2 家族）

SHA（Secure Hash Algorithm）由美国 NSA 设计，发表于 1993 年。SHA-256 是 SHA-2 系列中最常用的版本。

• 输出长度 — 256 比特（32 字节）
• 安全强度 — 128 比特（时间成本 2^128）
• 速度 — 快（现代 CPU 可达 GB/s）
• 使用场景 — 文件完整性检查、区块链、TLS、一般哈希

至今仍被广泛使用，安全性已被 30 年的实践验证。

SHA-3（最新标准）

2015 年，NIST 采纳 SHA-3 为新的标准哈希算法。基于 Keccak 算法，采用完全不同的数学结构（海绵函数）。

• 输出长度 — 256 比特（32 字节）或更长
• 安全强度 — 128+ 比特
• 速度 — 中等（比 SHA-256 略慢）
• 特点 — 对位翻转、边界情况更鲁棒

SHA-2 vs SHA-3 对比

选择建议

• 现有项目 — SHA-256 完全足够，无需迁移
• 新项目 — 优先使用 SHA-3-256（更新、更稳健）
• 密码存储 — 使用 bcrypt 或 argon2，不直接用 SHA-256

8. 为什么 MD5 和 SHA-1 已死

MD5（1992）— 永远不要用

MD5 输出 128 比特，一度很受欢迎。但在 2004 年，王小云证明了 MD5 的碰撞（两个不同输入产生相同哈希）。

风险：

• 不能用于文件完整性检查（攻击者可修改文件和哈希）
• 不能用于数字签名（可伪造签名）
• 不能用于密码存储（虽然密码本身一般不会碰撞，但多个 MD5 数据库可互通）

SHA-1（1995）— 基本退役

SHA-1 输出 160 比特，比 MD5 更强，长期被用于 HTTPS 证书和 Git。但在 2017 年，Google 和 CWI Amsterdam 联合发表了 SHA-1 的实际碰撞（SHAttered 项目）。

• 难度远低于理论，实际可在数周内计算
• 2019 年，主流浏览器完全停止接受 SHA-1 证书
• Git 社区正逐步迁移到 SHA-256

现在应该做什么