企业官网建设流程全解析

• 文档
• 教程
• 后端

导读

本文围绕 Node.js 最佳实践清单（nodebestpractices）安全章节中的核心条目展开：在存储用户密码时，应优先使用自适应哈希算法 bcrypt（bcrypt npm 模块），而不是 Node.js 原生crypto模块的简单哈希，并彻底摒弃可预测的Math.random()。读完本文，你将掌握 bcrypt 的rounds（工作因子）如何从时间维度拖垮暴力破解、如何在真实项目中完成密码的哈希与校验，以及加盐、密码长度上限等配套安全措施。

为什么存储密码不能直接使用 Node.js 原生 Crypto 库

许多开发者会本能地调用crypto.createHash('sha256')之类的 API 来"加密"用户密码，这是一个常见的误区。Node.js 原生crypto模块提供的 SHA-256、MD5 等通用哈希算法设计目标在于快速计算——速度快恰恰是密码破解者的福音：他们可以用 GPU 集群每秒完成数十亿次猜测，通过彩虹表与碰撞攻击迅速还原弱密码。

而 bcrypt 属于自适应哈希算法（adaptive hash algorithm），其核心设计思路是让单次哈希计算"刻意变慢"。在存储用户密码时，官方最佳实践清单明确建议使用 bcrypt，而不是 Node.js 原生 crypto 模块。

为什么Math.random()必须被禁止

Math.random()基于可预测的伪随机数生成器，其输出序列在一定条件下可以被推断，因此绝不能作为密码或令牌生成的一部分。凡是涉及安全凭据（密码盐值、会话令牌、重置链接）的随机性，都应交给专门的密码学安全随机源或算法内部自带的随机机制。

理解 rounds：bcrypt 抵御暴力破解的"时间武器"

bcrypt 与普通哈希函数最本质的区别，在于可以通过指定rounds（回合数）来调节计算强度：

• rounds 定义了工作因子（work factor），即数据被迭代处理的次数；
• 回合数越多，生成的哈希越安全，但代价是消耗更多 CPU 时间；
• 引入哈希回合意味着暴力破解因子被显著降低——密码破解者每生成一次尝试都要付出成倍的时间成本，整体破解进度被大幅拖慢。

这个"以时间换安全"的设计，正是 Max McCarty 在《Node.js and Password Storage with bcrypt》中所强调的观点：

……不只是使用正确的哈希算法。我广泛讨论了正确的工具如何把必要的成分"时间"作为密码哈希算法的一部分，以及它对试图通过暴力破解密码的攻击者意味着什么。

换句话说：正确的算法 + 可控的时间成本，两者缺一不可。如果只用快速哈希，数据库泄露后密码几乎等于明文；而 bcrypt 让每一次暴力猜测都变得昂贵，从而把攻击者的成本推高到不现实的水平。

实战代码：异步哈希与校验

下面的示例展示了 bcrypt 的两种核心操作——生成哈希与比对密码（完整示例见 bcryptpasswords 文档）：

// 使用 10 个哈希回合异步生成安全密码 bcrypt.hash('myPassword', 10, function(err, hash) { // 在用户记录中存储安全哈希 }); // 将用户输入的密码与已保存的哈希进行比对 bcrypt.compare('somePassword', hash, function(err, match) { if(match) { // 密码匹配 } else { // 密码不匹配 } });

要点说明：

• bcrypt.hash(password, rounds, callback)的第一个参数是明文密码，第二个参数是 rounds 数，回调中拿到的是包含盐值的自包含哈希字符串，可直接存入数据库；
• bcrypt.compare(plain, hash, callback)负责校验：内部会自动从哈希中提取盐值并重新计算，无需手动管理盐；
• 注意：示例中的10只是说明性取值。仓库中更完整的 userpasswords 指南 明确给出了生产环境的最低要求：cost: 12。更高的 cost 会显著增加单次计算耗时，请在服务器性能与安全性之间做权衡。

推荐的现代写法：async/await

在支持 async/await 的 Node.js 环境中，可以采用更简洁的写法（参见 userpasswords.md）：

const iterations = 12; try { // 异步生成安全密码 const hash = await bcrypt.hash('myPassword', iterations); // 在用户记录中存储安全哈希 // 将用户输入的密码与已保存的哈希进行比对 const match = await bcrypt.compare('somePassword', hash); if (match) { // 密码匹配 } else { // 密码不匹配 } } catch { logger.error('could not hash password.') }

密码存储的完整方案对比：bcrypt / scrypt / PBKDF2

仓库的 userpasswords 指南 给出了三种主流的密码哈希方案，供不同场景选择。无论选择哪一种，都必须正确实现，并且始终在哈希前加入盐值（salt）：

三种方案各有取舍：

• bcrypt：外部依赖，但兼容性与社区支持最好，是"能用就用"的首选；
• scrypt：相比 bcrypt 是轻微改进，支持无限长度密码且无额外依赖，但需要更多配置参数，且相对较新、经受过的时间检验更少。它通过 cost（提高 CPU/内存成本）、blockSize（提高内存成本）与并行度（提高拆分计算的成本）三组参数共同决定安全强度；
• PBKDF2：仅当 FIPS 或其他合规要求绝对必要时使用，其 API 与 bcrypt 类似，同样通过迭代次数控制强度与耗时。

此外，密码哈希竞赛（Password Hashing Competition）的冠军 Argon2 被 OWASP 与 IETF 推荐为顶级现代算法，一旦随 OpenSSL 进入 Node.js 原生 crypto 模块并稳定，将优先采用。

配套安全措施：盐值、密码长度与随机性

为什么必须加盐（Salt）

无论使用哪种算法，都应加入一个"专属于你的系统 + 专属于该用户"的字符串作为盐值，例如"用户名/用户 ID + 应用名"或"用户邮箱 + 业务邮箱"的组合。加盐的作用在于：

• 同一密码在不同系统、不同用户下产生不同的哈希，数据库泄露后无法与别处数据泄露的哈希对撞；
• 当所有用户都使用唯一盐值时，攻击者几乎无法通过预计算彩虹表识别密码复用模式。

需要留意的是，bcrypt 对输入长度有限制（密码 + 盐总长度须控制在 64 字符以内），而 scrypt 对盐与密码长度几乎没有限制。

密码长度与预哈希策略

如果你的密码加上盐值必须满足长度上限，可以考虑在客户端预先做一次简单哈希（预哈希，pre-hash），例如在浏览器中使用const hash = crypto.subtle.digest('sha-256', password)生成定长十六进制字符串再传给服务端。这样做既能对 API 施加严格的输入校验（如仅允许恰好 256 个十六进制字符），又不限制用户使用任意长度和任意字符的密码。注意预哈希本身也要选择足够好的哈希以规避碰撞。

随机性：把随机数交给算法

在密码安全领域，应尽可能把随机性的生成交给所选算法内部完成，bcrypt 与 scrypt 都会自动生成加密安全的盐。文档特别提醒：不仅Math.random()不能用，甚至应避免自行大量调用crypto.random()——随机性在计算机上是一种稀缺资源，滥用会拖累你的程序乃至同机上的其他程序。

原理小结：bcrypt/scrypt 为何难以被暴力破解

bcrypt 与 scrypt 的共同前提是：如果合法用户哈希一次密码需要 X 的成本与时间，而攻击者暴力破解需要付出 X 的若干次方量级的资源，那么通过"哈希的哈希的哈希……"（迭代）就能指数级放大攻击者所需投入的资源。scrypt 还额外引入块大小与并行度参数，试图针对"攻击者假设只需一定内存或 CPU 核心数"的硬件破解模型增加难度（尽管这些参数的实际有效性在业界仍有讨论）。

进一步阅读

• 本文核心依据：bcryptpasswords.brazilian-portuguese.md（另有 中文版）
• 完整密码存储指南（含 scrypt、PBKDF2 代码示例与参数明细）：userpasswords.md
• 同属安全章节的配套条目，可组合阅读：commonsecuritybestpractices.md、avoid_publishing_secrets.md、secretmanagement.md

• 文档
• 教程
• 后端