1. 项目概述：为什么我们还在讨论加密算法？

如果你在十年前问我，一个项目里用什么做密码加密，我大概率会脱口而出：“MD5啊，简单好用。” 那时候，MD5几乎是开发者工具箱里的标配，从用户密码存储到文件完整性校验，随处可见它的身影。但今天，如果你在新启动的项目里，还在用MD5处理用户密码，那基本等于在系统安全的大门上贴了一张“欢迎光临”的纸条。这不是危言耸听，而是这十多年来，计算能力和攻击手段的演进，让一些曾经“足够安全”的算法，变成了不堪一击的软肋。

这个项目，或者说这次探讨，源于我最近一次代码审计。在审查一个老系统的安全加固方案时，我发现其用户表里依然躺着大量MD5加密的密码哈希值。团队负责人很困惑：“MD5不是加密算法吗？为什么突然就不安全了？” 这个问题让我意识到，很多开发者对于加密算法的理解，还停留在“能用就行”的阶段，对于算法背后的原理、演进历程以及如何根据场景选择，缺乏一个系统性的认知。

所以，我想通过这篇文章，彻底拆解从MD5到BCrypt，乃至更多现代加密算法的核心逻辑。这不是一篇枯燥的算法教科书，而是一个一线开发者，结合无数次踩坑、选型、重构的经验，为你梳理的实战指南。我们会深入探讨：MD5为什么会被淘汰？BCrypt凭什么成为当下密码存储的黄金标准？在不同的应用场景下，比如快速校验、数据签名、密钥派生，我们又该如何选择？我会用最直白的语言，把哈希、盐值、工作因子这些概念讲清楚，并附上可直接“抄作业”的代码示例和配置参数。无论你是刚入行的新手，还是经验丰富的老兵，相信都能从中找到对你有用的东西。

2. 核心概念辨析：哈希、加密与编码

在深入具体算法之前，我们必须先厘清几个最基础也最容易被混淆的概念：哈希、加密和编码。很多安全问题的根源，就在于错误地使用了这些技术。

2.1 哈希：单向的指纹

哈希函数，比如MD5、SHA-256，它的核心特性是单向性和确定性。你给哈希函数输入任意长度的数据（比如一个密码“hello123”），它会输出一个固定长度的、看起来像乱码的字符串（称为哈希值或摘要）。这个过程是单向的，理论上你无法从这个哈希值反推出原始的输入数据。同时，相同的输入永远产生相同的输出。

哈希的主要用途是完整性校验和指纹生成。比如你下载一个软件，官网会提供它的SHA-256哈希值。你下载后自己计算一遍文件的哈希值，如果两者一致，就证明文件在传输过程中没有被篡改。在密码存储场景中，我们存储的是密码的哈希值，而非明文密码。当用户登录时，系统对用户输入的密码再次进行哈希运算，然后与数据库中存储的哈希值进行比对。这样，即使数据库泄露，攻击者拿到的也只是哈希值，而非原始密码。

注意：这里有一个巨大的误区。很多人，包括一些早期的系统设计，会使用哈希函数（如MD5）对密码进行“加密”。严格来说，这不能叫加密，而是“哈希处理”。加密是可逆的（有密钥就能解密），而哈希是不可逆的。这个用词的区别，反映了对技术本质理解的差异。

2.2 加密：可逆的伪装

加密算法，如AES、RSA，其核心目的是机密性。它通过一个密钥，将明文数据转换为密文，并且可以通过对应的密钥（或同一密钥）将密文还原为明文。加密是双向的、可逆的操作。

加密根据密钥的使用方式，主要分为两类：

• 对称加密：加密和解密使用同一个密钥，如AES。速度快，适合加密大量数据，但密钥分发和管理是挑战。
• 非对称加密：使用公钥和私钥对，如RSA。公钥公开用于加密，私钥保密用于解密。解决了密钥分发问题，但速度较慢，通常用于加密小数据（如会话密钥）或数字签名。

在密码存储中，绝对不应该使用标准加密算法。因为一旦密钥泄露，所有密码都将被解密。而哈希函数没有密钥，泄露数据库并不会直接导致密码泄露（虽然可以通过彩虹表等方式攻击，这是后话）。

2.3 编码：可逆的转换

编码，比如Base64、URL Encoding，它不是为了安全，而是为了数据表示。它的目的是确保数据能在特定的系统或协议中（如HTTP、电子邮件）被正确传输和存储，因为这些环境可能不支持原始二进制数据。编码是公开的、完全可逆的转换，没有任何保密性可言。

一个常见的错误是，有人把Base64编码的字符串当作“加密”结果。Base64只是把二进制数据用64个字符重新表示了一下，任何人都可以轻松解码回原始数据，毫无安全性。

总结一下三者的核心区别：

理解了这些，我们就能明白，为什么密码存储的首选技术是哈希，而不是加密。接下来，我们就从那个曾经辉煌的MD5开始，看看哈希算法是如何演进的。

3. MD5的辉煌与陨落：一个时代的缩影

MD5（Message-Digest Algorithm 5）由Ron Rivest在1991年设计，它生成一个128位（16字节）的哈希值，通常表示为32个十六进制数字。在千禧年前后，MD5因其计算速度快、实现简单、碰撞率低（当时认为）而风靡全球。

3.1 MD5的工作原理与典型应用

MD5属于密码学哈希函数，它会对输入数据进行一系列复杂的位运算（包括填充、分块、循环处理等），最终压缩成那个固定的128位摘要。在早期，它被广泛应用于：

1. 文件完整性校验：软件发布者提供文件的MD5值，供下载者校验。
2. 密码存储：系统存储md5(password)。
3. 数据指纹/唯一标识：比如用MD5值作为数据库记录的唯一键或缓存键。

下面是一个简单的Java示例，展示了如何使用MD5（请注意，这仅用于演示历史用法，绝对不要在新项目中使用）：

import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; public class OutdatedMD5Demo { public static String getMD5(String input) { try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] messageDigest = md.digest(input.getBytes()); // 将字节数组转换为十六进制字符串 StringBuilder hexString = new StringBuilder(); for (byte b : messageDigest) { String hex = Integer.toHexString(0xff & b); if (hex.length() == 1) hexString.append('0'); hexString.append(hex); } return hexString.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } } public static void main(String[] args) { String password = "MySecretPassword123"; String hashedPassword = getMD5(password); System.out.println("MD5 Hash: " + hashedPassword); // 输出类似：34819d7beeabb9260a5c854bc85b3e44 } }

3.2 MD5为何不再安全？

MD5的衰落不是一夜之间发生的，而是一个随着计算能力提升和密码学分析突破而逐渐崩塌的过程。其主要安全问题集中在两点：

1. 碰撞攻击的突破：哈希函数的“碰撞”是指两个不同的输入产生了相同的哈希值。一个安全的哈希函数应该极难找到碰撞。然而：

• 2004年，王小云教授团队首次公开演示了MD5的碰撞攻击。他们能在可接受的时间内，找到两个产生相同MD5值的不同文件。
• 后续攻击不断优化，甚至可以在普通计算机上快速制造碰撞。

这意味着什么？假设一个系统用MD5校验文件完整性。攻击者可以精心构造一个恶意软件A和一个正常文件B，使它们的MD5值相同。那么当你下载并校验B的MD5时，它会和官网提供的A的MD5值匹配，让你误以为文件是安全的。在密码学领域，这已经宣判了MD5在需要防篡改场景下的“死刑”。

2. 彩虹表与高速破解：即使不考虑碰撞，MD5用于密码存储也极其脆弱。

• 速度太快：现代GPU每秒可以计算数百亿次MD5哈希。一个6位纯数字密码（000000-999999）的MD5值，可以在瞬间被全部计算并比对出来。
• 彩虹表攻击：攻击者事先计算出海量常用密码及其对应MD5值的映射表（即彩虹表）。当拿到数据库泄露的MD5哈希值时，只需在表中查询即可快速得到原始密码。网络上存在高达数万亿条记录的彩虹表，覆盖了绝大多数用户的简单密码。

3. 无盐值设计（在传统用法中）：早期的MD5密码存储，通常是md5(password)。这意味着，所有使用相同密码的用户，其哈希值也完全相同。攻击者破解了一个密码，就等于破解了所有使用该密码的账户。

实操心得：我见过最令人啼笑皆非的“安全加固”，是在MD5哈希前给密码加了一个固定的字符串，比如md5("prefix" + password)。这本质上只是一个更复杂的“盐”，但因为是固定的、统一的，攻击者只需在生成彩虹表时同样加上这个前缀即可，安全增益几乎为零。真正的盐值必须是随机的、每个用户独立的。

由于上述致命缺陷，NIST等权威机构早在十多年前就明确建议停止将MD5用于任何安全目的。现在，它唯一安全的用途可能只剩下非安全相关的校验，比如作为缓存键的一部分（仍需注意碰撞可能导致错误覆盖）。对于密码存储和文件完整性校验，必须使用更安全的替代品。

4. 现代密码存储的基石：BCrypt深度解析

当MD5倒下后，密码存储领域并没有简单地转向更快的SHA-256。因为SHA-256虽然抗碰撞能力强，但计算速度也很快（在GPU上依然能被暴力破解）。密码存储需要一个专门为“慢”而设计的算法，这就是自适应哈希函数，而BCrypt是其中的杰出代表。

4.1 BCrypt的核心设计思想

BCrypt由Niels Provos和David Mazières在1999年设计，其核心思想可以概括为：通过一个可配置的成本因子（work factor），故意让哈希计算过程变慢，从而极大增加暴力破解的难度。

你可以把它想象成一把非常复杂的机械锁。开锁（计算哈希）的过程本身就需要耗费一定时间（比如10毫秒）。对于合法用户来说，登录时多等10毫秒毫无感知。但对于攻击者来说，他要尝试数十亿个密码，每个密码都需要10毫秒，总时间就变成了一个天文数字，使得暴力破解在经济和时间上变得不可行。

BCrypt的“慢”主要来自于它内部使用了基于Blowfish加密算法的密钥扩展过程，并通过多次迭代（由成本因子控制）来增加计算开销。

4.2 BCrypt的工作因子与盐值机制

一个BCrypt哈希字符串长这样：$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy我们来拆解一下：

• $2a$: 标识BCrypt的版本。
• $10$:成本因子（work factor）。这里的“10”表示迭代次数是2的10次方，即1024轮。这个因子是可调的（通常4-31）。因子每增加1，计算时间大约翻一倍。10是一个当前比较平衡的推荐值（约100毫秒内）。
• N9qo8uLOickgx2ZMRZoMye: 随机生成的22字符的盐值。BCrypt在哈希过程中会自动生成并包含盐值。
• IjZAgcfl7p92ldGxad68LJZdL17lhWy: 计算出的60位的哈希值。

盐值的作用至关重要：即使两个用户的密码相同，由于盐值不同，最终存储的哈希值也完全不同。这彻底摧毁了彩虹表的有效性，因为攻击者必须为每个盐值单独建立彩虹表，成本极高。

4.3 如何在项目中使用BCrypt

在实际开发中，我们几乎从不自己实现BCrypt算法，而是使用成熟的安全库。以下是在不同语言中的使用示例：

Java (使用 Spring Security 的 BCryptPasswordEncoder):

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; public class BCryptDemo { public static void main(String[] args) { BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(12); // 设置成本因子为12 String rawPassword = "MySecretPassword123"; // 加密密码（自动生成盐并包含在结果中） String encodedPassword = encoder.encode(rawPassword); System.out.println("BCrypt Hash: " + encodedPassword); // 验证密码 boolean isMatch = encoder.matches(rawPassword, encodedPassword); System.out.println("Password matches: " + isMatch); // 输出：true // 验证错误密码 boolean isWrongMatch = encoder.matches("WrongPassword", encodedPassword); System.out.println("Wrong password matches: " + isWrongMatch); // 输出：false } }

Python (使用 bcrypt 库):

import bcrypt # 生成盐并哈希密码 password = b"MySecretPassword123" # cost factor 默认为12，可根据硬件调整 hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12)) print(f"BCrypt Hash: {hashed.decode('utf-8')}") # 验证密码 if bcrypt.checkpw(password, hashed): print("Password matches") else: print("Password does not match")

Node.js (使用 bcryptjs 库):

const bcrypt = require('bcryptjs'); const saltRounds = 12; // 成本因子 const password = 'MySecretPassword123'; // 异步哈希 bcrypt.hash(password, saltRounds, function(err, hash) { if (err) throw err; console.log('BCrypt Hash:', hash); // 异步验证 bcrypt.compare(password, hash, function(err, result) { console.log('Password matches:', result); // true }); bcrypt.compare('WrongPassword', hash, function(err, result) { console.log('Wrong password matches:', result); // false }); });

注意事项：选择成本因子时，需要在安全性和用户体验间取得平衡。一个实用的方法是：在你的生产服务器上，测试不同因子下哈希一个密码所需的时间，目标是让时间在100毫秒到1秒之间。对于Web应用，100-500毫秒是常见的可接受范围。随着硬件性能提升，这个因子应该每隔几年重新评估并适当增加。

4.4 BCrypt的局限性

BCrypt并非完美无缺：

• 最大密码长度限制：早期版本（如$2a$）对密码长度有72字符的限制，超出的部分会被忽略。较新的版本（如$2b$,$2y$）修复了相关问题，但如果你需要支持超长密码，需要注意库的版本。
• GPU/ASIC抵抗性：BCrypt的内存访问模式使其在GPU和专用硬件（ASIC）上的加速效果不如SHA系列明显，但并非完全免疫。针对大规模攻击，仍有更专业的算法。

尽管如此，对于绝大多数Web应用、移动应用和企业系统的密码存储需求，BCrypt仍然是当前最可靠、最被广泛推荐的选择之一。

5. 更广阔的算法图谱：PBKDF2、Scrypt与Argon2

BCrypt是自适应哈希函数的优秀代表，但并非唯一选择。根据不同的威胁模型和场景，我们还有其他强有力的候选者。

5.1 PBKDF2：标准与兼容之选

PBKDF2（Password-Based Key Derivation Function 2）由RSA实验室制定，并被包括NIST在内的多个标准机构推荐。它本身不是一个哈希函数，而是一个密钥派生函数，通过多次迭代一个伪随机函数（通常是HMAC-SHA256）来从密码中派生密钥。

工作原理：派生密钥 = PBKDF2(密码, 盐, 迭代次数, 密钥长度)高迭代次数（如10万次以上）是其抵抗暴力破解的关键。

优点：

• 标准化：被广泛的标准和协议支持，兼容性极好。
• 可配置性强：可以自由选择底层的哈希函数（如SHA-256）、迭代次数和输出长度。
• 无长度限制：对输入密码长度没有限制。

缺点：

• 对GPU攻击防御较弱：由于其计算主要是CPU密集型，在GPU上并行破解的效率依然很高。
• 内存消耗低：不消耗大量内存，使得攻击者可以使用成本更低的硬件进行大规模并行攻击。

应用场景：适用于需要严格遵循特定标准（如FIPS）的环境，或者与其他系统进行互操作的场景。也常用于从密码派生加密密钥。

Java示例 (使用 PBKDF2WithHmacSHA256):

import javax.crypto.SecretKeyFactory; import javax.crypto.spec.PBEKeySpec; import java.security.NoSuchAlgorithmException; import java.security.spec.InvalidKeySpecException; import java.util.Base64; public class PBKDF2Demo { public static String hashPassword(String password, String salt) throws NoSuchAlgorithmException, InvalidKeySpecException { int iterations = 100000; // 迭代次数，可根据需要调整 int keyLength = 256; // 派生密钥长度 PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(), iterations, keyLength); SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); byte[] hash = skf.generateSecret(spec).getEncoded(); return Base64.getEncoder().encodeToString(hash); } }

5.2 Scrypt：引入内存成本

Scrypt由Colin Percival设计，旨在同时增加时间成本和内存成本。它不仅像BCrypt和PBKDF2一样进行大量计算，还会在计算过程中消耗大量内存（可配置）。这使得攻击者即使拥有强大的GPU，也会因为昂贵的显存需求而难以进行大规模并行攻击。

核心思想：制造一个需要大量、连续内存空间的计算过程，而不仅仅是CPU周期。定制硬件（ASIC）和GPU通常具有强大的计算能力，但显存相对昂贵且并行访问模式受限，Scrypt能有效提高其攻击成本。

优点：

• 强大的GPU/ASIC抵抗性：高内存需求是其最大优势。
• 可配置内存和CPU成本：参数灵活。

缺点：

• 配置复杂：需要仔细调整内存和工作因子参数，配置不当可能导致服务拒绝（DoS）攻击（因为合法登录请求也会消耗大量资源）。
• 支持库相对较少：不如BCrypt和PBKDF2普及。

应用场景：特别适用于保护价值非常高的密钥，如加密货币钱包的助记词加密。在普通Web应用中也是一种优秀的选择。

5.3 Argon2：密码哈希竞赛的冠军

Argon2是2015年密码哈希竞赛（Password Hashing Competition）的获胜者，被公认为当前最先进的密码哈希算法。它提供了三种变体：

• Argon2i：抗侧信道攻击，适用于需要防范基于时间的侧信道攻击的场景。
• Argon2d：抗GPU破解能力最强，但可能泄露一些内存访问模式信息。
• Argon2id（推荐）：Argon2i和Argon2d的混合模式，在大多数场景下是最佳选择，平衡了安全性和性能。

Argon2同时优化了时间、内存和并行计算成本，使得在定制硬件上攻击的性价比极低。

优点：

• 安全性最高：现代设计，抵抗多种硬件攻击。
• 灵活的参数配置：可独立调整时间成本、内存成本和并行度。
• 被广泛推荐：是OWASP等权威安全机构当前的首推密码哈希算法。

缺点：

• 相对较新：在一些老旧系统或语言中的库支持可能不如BCrypt成熟。
• 计算资源消耗：配置不当可能对服务器负载影响较大。

应用场景：新项目的首选，尤其是对安全性要求极高的系统。随着时间推移，它很可能成为新的行业标准。

Java示例 (使用 Argon2PasswordEncoder from Spring Security 5+):

import org.springframework.security.crypto.argon2.Argon2PasswordEncoder; public class Argon2Demo { public static void main(String[] args) { // 参数：盐长度，哈希长度，并行度，内存成本(KB)，迭代次数 Argon2PasswordEncoder encoder = new Argon2PasswordEncoder(16, 32, 1, 65536, 3); String rawPassword = "MySecretPassword123"; String encodedPassword = encoder.encode(rawPassword); System.out.println("Argon2 Hash: " + encodedPassword); boolean isMatch = encoder.matches(rawPassword, encodedPassword); System.out.println("Password matches: " + isMatch); } }

6. 实战选型指南：不同场景下的算法选择

了解了这么多算法，到底该用哪个？没有放之四海而皆准的答案，关键看你的应用场景和威胁模型。

6.1 场景一：用户密码存储（Web/App后端）

这是最经典的需求。你的目标是：即使数据库被拖库，攻击者也无法在合理时间内破解出大部分用户的明文密码。

首选推荐：Argon2id理由：它是当前最强的算法，能有效抵御GPU、ASIC等定制硬件的攻击。对于新项目，无脑选它。次选/稳妥之选：BCrypt理由：经过近20年的实战检验，库支持极其广泛，社区知识丰富，安全性足够应对绝大多数场景。如果你担心Argon2的库在某些环境不够稳定，BCrypt是最可靠的备胎。标准兼容之选：PBKDF2（配置高迭代次数）理由：当你的系统需要符合某些强制标准（如FIPS 140-2），或者与大量遗留系统交互时，PBKDF2是安全且合规的选择。绝对禁止：MD5、SHA-1、SHA-256（不加盐或简单哈希）理由：这些算法速度太快，无法抵御离线暴力破解。

配置参数参考（以BCrypt为例）：

• 成本因子 (Work Factor)：从10或12开始。在您的生产硬件上测试，确保单次哈希时间在100-500毫秒。每1-2年评估一次，随着硬件升级，将因子提高1。

6.2 场景二：文件或数据完整性校验

你需要验证一个文件在传输或存储后是否未被修改。例如：软件包分发、区块链中的交易验证。

首选：SHA-256 或 SHA-3理由：这类场景不需要抵抗“原像攻击”（从哈希反推数据），但需要极强的抗碰撞能力，确保两个不同的文件不会产生相同的哈希值。SHA-256和SHA-3速度很快，非常适合处理大文件，且抗碰撞性远强于已破的MD5和SHA-1。绝对禁止：MD5、SHA-1理由：碰撞攻击已被证实，攻击者可以伪造具有相同哈希值的恶意文件。

6.3 场景三：派生加密密钥

你需要从一个密码（或口令）派生出用于对称加密（如AES）的密钥。

首选：PBKDF2 或 Argon2理由：密钥派生函数（KDF）是专门为此设计的。PBKDF2被许多加密标准采用。Argon2作为更现代的KDF，安全性更高。通过高迭代次数/成本因子，可以确保派生出的密钥具有足够的熵（随机性）。方法：使用密码、随机盐和高成本因子，派生出一个长度合适的密钥（如AES-256需要256位密钥）。

6.4 场景四：生成唯一标识或缓存键

你需要为一个数据块生成一个短且唯一的标识符，用于数据库键、缓存键或ETag。

可以考虑：MD5 或 SHA-1（仅限非安全场景！）理由：在这个场景下，我们不在乎碰撞攻击带来的安全风险，只在乎速度和哈希值的分布均匀性。例如，用文件内容的MD5值作为Redis缓存键。即使发生极其罕见的碰撞，也顶多是缓存错乱，不会导致安全漏洞。更佳选择：xxHash, MurmurHash 等非加密哈希理由：这些算法比MD5更快，碰撞率在非安全场景下也可接受，是专门为哈希表、校验和等场景设计的。重要提示：必须明确区分系统边界。绝对不允许将用于缓存键的MD5哈希函数，与用于密码处理的哈希函数混用同一个库或同一个函数调用，以防误用。

6.5 选型决策速查表

7. 实施要点与常见陷阱

选择了正确的算法只是第一步，错误地实施同样会导致严重的安全漏洞。

7.1 盐值管理：随机、唯一、足长

盐值是用来防御彩虹表攻击的。最佳实践是：

• 每个密码一个随机盐：绝对不要使用全局固定的盐，或者基于用户ID生成的盐。
• 使用密码学安全的随机数生成器：如Java的SecureRandom，Python的os.urandom。
• 足够长：盐值长度至少16字节（128位）。
• 与哈希一起存储：像BCrypt、Argon2等现代算法，会自动将盐值混入最终的哈希字符串中并一起存储，无需单独管理盐值字段。如果你使用PBKDF2等需要自己管理盐的算法，必须将盐值和哈希值分开存储（通常并存于同一个字段或用分隔符分开）。

7.2 密码策略与哈希加固

算法不能解决弱密码问题。必须实施前端和后端的密码策略：

• 最小长度：至少8位，推荐12位以上。
• 复杂度要求：鼓励但不强制要求大小写字母、数字、符号混合。最新的NIST指南更推荐长度而非过度复杂的规则，因为复杂的规则会导致用户使用可预测的变形（如Password123!）。
• 检查常见弱密码：在哈希之前，将用户输入的密码与一个常见的弱密码列表（如rockyou.txt）进行比对，拒绝使用这些密码。
• 哈希加固（Peppering）：在哈希计算之外，额外增加一个全局的、保密的“胡椒”（pepper）。这可以是一个存储在应用服务器配置文件或硬件安全模块中的密钥。流程是：最终存储值 = 哈希(密码 + 用户唯一盐) + 胡椒(加密或二次哈希)。即使数据库完全泄露，攻击者没有胡椒也无法进行有效的离线破解。这为系统增加了一层纵深防御。

7.3 升级已有系统的哈希策略

对于遗留系统，不可能一次性将所有MD5密码强制升级。一个平滑的迁移策略是：

1. 双轨制验证：用户登录时，先用新算法（如BCrypt）验证。如果失败，再用旧算法（MD5）验证。如果旧算法验证成功，立即用新算法计算其哈希值并更新数据库，然后作废旧的MD5哈希。
2. 标记与强制更新：在用户表中增加一个字段（如password_version），标识密码使用的算法版本。对于使用旧版本的用户，可以在下次登录成功时强制要求修改密码。
3. 渐进式重哈希：后台运行一个低优先度的任务，分批读取用户记录，对仍使用旧哈希的密码进行验证和重哈希。注意，你无法从MD5哈希反推密码，所以这个任务只能等待用户下次登录时触发。

7.4 常见问题排查实录

问题1：BCrypt哈希验证总是失败。

• 可能原因A：盐值处理错误。如果你是自己生成盐并调用底层函数，确保验证时使用的是和哈希时完全相同的盐。最佳实践是使用库的高级API（如encode和matches方法），让库自动处理盐值。
• 可能原因B：密码字符串编码问题。确保在哈希和验证时，密码字符串到字节数组的转换编码一致（如UTF-8）。
• 排查步骤：使用一个已知的密码和盐，用在线BCrypt计算器或另一个库验证你的哈希输出是否一致。

问题2：哈希操作导致服务器CPU负载过高，登录接口变慢。

• 可能原因：成本因子设置过高。在用户登录高峰期，大量的并发哈希计算会耗尽CPU资源。
• 解决方案：
  • 适当降低成本因子：在安全可接受的范围内调整。可以先降到10或11。
  • 引入限流：对登录接口进行限流，防止恶意暴力请求。
  • 考虑异步或队列：对于非实时性的密码操作（如批量导入用户后的密码哈希），放入后台任务队列处理。
  • 硬件升级：密码哈希本就是有意消耗资源的操作，确保你的服务器有足够的计算能力。

问题3：从其他系统迁移用户，只有MD5哈希，没有明文密码，怎么办？

• 这是最棘手的情况。你无法直接升级。策略是：
  1. 将这些MD5哈希值当作“密码”一样，用新的安全算法（如BCrypt）再哈希一次并存储。即：最终存储值 = BCrypt(MD5哈希值 + 盐)。
  2. 在登录验证时，流程变为：用户输入明文密码 -> 计算MD5 -> 用BCrypt验证上一步的结果。
  3. 这只是一个临时方案，安全性等同于MD5。必须在用户下次登录时，通过其他方式（如短信验证、邮件链接）强制其重置密码，然后用新算法直接哈希明文密码，替换掉那个“双哈希”值。

加密算法的选型与应用，远不止于调用一个API。它关乎对技术原理的深刻理解、对应用场景的准确判断，以及一丝不苟的实施细节。从MD5的简单易用到被淘汰，再到BCrypt、Argon2等算法的主动增加攻击成本，这背后是安全攻防永不停息的博弈。作为开发者，我们的责任是跟上这些变化，在系统的基石处做出明智而坚固的选择。记住，在安全领域，懒惰和过时的知识，往往是最大的漏洞。