PBKDF2 详解：算法原理、迭代次数与盐值

密码学里有个很实在的问题：用户设置的密码通常不够随机。你想想看，123456、password 这种密码，在彩虹表面前基本就是裸奔。PBKDF2 就是来解决这个问题的——它把弱密码「拉伸」成强密钥。

我个人习惯把 PBKDF2 叫做「密码健身教练」。它逼着攻击者做大量重复计算，让暴力破解的成本高到难以承受。嗯，咱们今天就把这个算法彻底讲透。

算法核心：HMAC 驱动的迭代循环

PBKDF2 的全称是 Password-Based Key Derivation Function 2。它的核心思想很简单：用密码和盐值做 HMAC 运算，然后反复迭代。

公式长这样：

DK = PBKDF2(PRF, Password, Salt, c, dkLen)

其中：
- PRF：伪随机函数，通常是 HMAC-SHA256
- Password：用户输入的密码
- Salt：随机盐值
- c：迭代次数
- dkLen：期望的派生密钥长度

具体计算过程分两步：

1. 生成足够长的块：把 dkLen 拆成若干块，每块长度等于 PRF 的输出长度。
2. 每块内部迭代：对每个块，用密码和盐值做 c 次 HMAC 运算，最后把所有块拼接起来。

我在项目中遇到过有人把迭代次数设成 1，那基本等于没设。你想想看，一次 HMAC 运算，GPU 一秒能算几百万次，密码跟明文有什么区别？

盐值：为什么不能省？

盐值的作用是防止预计算攻击。说白了，就是让每个用户的密码都加上一个「独一无二的调料」。

场景	无盐值	有盐值
彩虹表攻击	一次预计算，破解所有用户	每个盐值需要单独建表
相同密码	哈希值相同，一眼看出	哈希值不同，无法关联
并行破解	可批量尝试	每个用户独立计算

盐值的要求：

• 长度至少 16 字节（128 位）
• 每个用户、每次密码变更都要重新生成
• 使用密码学安全的随机数生成器

我曾经见过一个系统，盐值是用户名的 MD5——这跟没加盐差不多。攻击者拿到用户名就能算出盐值，预计算攻击照样有效。

迭代次数：多少才够？

这是个动态问题。摩尔定律让攻击者的算力逐年增长，所以迭代次数也要跟着涨。

我建议的参考值（2024 年标准）：

应用场景	最低迭代次数	推荐迭代次数
Web 应用登录	100,000	600,000
移动端应用	50,000	200,000
IoT 设备	10,000	50,000
文件加密	100,000	1,000,000

为什么会有差异？因为不同设备的计算能力不同。移动端和 IoT 设备 CPU 弱，迭代次数太高会导致用户体验变差。但 Web 服务器有充足的计算资源，可以设高一些。

Python 实现：从零手写

虽然 Python 标准库有 hashlib.pbkdf2_hmac，但理解底层实现很重要。下面是我手写的一个简化版：

import hmac
import hashlib
import struct

def pbkdf2_hmac_sha256(password, salt, iterations, dklen=32):
    """
    PBKDF2-HMAC-SHA256 实现
    
    参数：
    - password: 密码（bytes）
    - salt: 盐值（bytes）
    - iterations: 迭代次数
    - dklen: 派生密钥长度（字节）
    
    返回：
    - 派生密钥（bytes）
    """
    # HMAC 输出长度（SHA256 是 32 字节）
    hlen = hashlib.sha256().digest_size
    
    # 计算需要的块数
    blocks = (dklen + hlen - 1) // hlen
    
    derived_key = b''
    
    for block in range(1, blocks + 1):
        # 初始输入：盐值 + 块号（大端序 4 字节）
        u = salt + struct.pack('>I', block)
        
        # 第一次 HMAC
        u = hmac.new(password, u, 'sha256').digest()
        t = u
        
        # 后续迭代
        for i in range(1, iterations):
            u = hmac.new(password, u, 'sha256').digest()
            # XOR 累加
            t = bytes(a ^ b for a, b in zip(t, u))
        
        derived_key += t
    
    # 截取需要的长度
    return derived_key[:dklen]

# 使用示例
password = b'my_secure_password'
salt = b'random_salt_16bytes'
key = pbkdf2_hmac_sha256(password, salt, 100000, 32)
print(key.hex())

安全建议：避坑指南

我曾经在审计一个金融系统时，发现他们把盐值硬编码在代码里。嗯，那感觉就像把保险柜密码贴在柜门上。

以下是我总结的几条铁律：

1. 盐值必须随机：用 os.urandom(16) 生成，不要用时间戳、用户名、UUID 等可预测值。
2. 迭代次数要可配置：写在配置文件里，方便后续升级。不要硬编码在代码中。
3. 密码长度有限制：PBKDF2 对长密码有性能问题。建议限制密码长度（比如 128 字节），超长密码先做 SHA256 哈希。
4. 使用标准库：不要自己实现 HMAC 或 PBKDF2。Python 的 hashlib、Java 的 SecretKeyFactory、Go 的 golang.org/x/crypto/pbkdf2 都是经过验证的。
5. 定期升级迭代次数：每 1-2 年重新评估一次。用户下次登录时，用新参数重新派生并更新存储。

PBKDF2 的局限性

说实话，PBKDF2 不是完美的。它有个明显的弱点：对 GPU 和 ASIC 友好。因为它的计算模式是 HMAC 循环，这种模式在并行硬件上跑得飞快。

相比之下，bcrypt 和 scrypt 引入了内存硬性要求，让 GPU 的优势大打折扣。而 Argon2（2015 年密码哈希竞赛冠军）更是同时控制了时间和内存两个维度。

我的建议是：

• 新系统优先用 Argon2id
• 遗留系统如果必须用 PBKDF2，迭代次数至少 600,000
• 不要自己设计「增强版」PBKDF2，那通常只会引入漏洞

下面这张图展示了 PBKDF2 的核心流程：

从流程图可以看出，PBKDF2 的核心就是「盐值 + 迭代」的组合。盐值让预计算失效，迭代让暴力破解变慢。两者配合，才能把弱密码变成强密钥。