如何高效实现抗暴力破解的Web密码工作量证明机制？

首先纠正你代码中的关键错误：你的hash_n_times函数逻辑有误，循环内每次哈希的是原始content而非上一次的哈希结果，导致无论循环多少次，最终结果都等于单次SHA-256哈希，完全起不到多次哈希的作用。正确的迭代哈希逻辑应该是：

function hash_n_times(content,n) {
    let hash = content;
    for (let _ = 0; _ < n; _++) { 
        hash = sha256_digest(hash); // 用前一次的哈希结果作为下一次的输入
    }
    return hash;
}

但即使修复这个问题，多次SHA-256这类纯CPU密集型哈希依然无法对抗矿机/ASIC的大规模并行攻击，以下是针对Web场景的高效优化方案：

一、改用内存密集型哈希函数 #

这类函数通过消耗大量内存带宽，限制ASIC和矿机的并行处理能力，同时在移动端只要参数调优，就能控制耗时在可接受范围（50-100ms），推荐以下两种：

1. Argon2（密码哈希竞赛冠军，首选） #

Argon2id变种兼顾抗ASIC攻击和抗侧信道攻击，Web环境可使用argon2-browser库实现，参数建议：

• 内存成本：16MB（1<<14），移动端压力小，矿机单线程内存占用高，并行数受限
• 时间成本：3-5次迭代，保证移动端耗时可控
• 并行度：1（Web环境单线程为主，避免阻塞UI）

示例代码：

import argon2 from 'argon2-browser';

async function hashPassword(password, salt) {
    const result = await argon2.hash({
        pass: password,
        salt: salt, // 每个用户唯一的随机salt，至少16字节
        time: 3,
        mem: 16384,
        type: argon2.ArgonType.Argon2id
    });
    return result.hashHex;
}

2. scrypt（成熟稳定，抗ASIC） #

scrypt通过内存硬限制提升攻击成本，适合Web场景，可用scrypt-js库实现，参数建议：

• N：16384（内存因子，对应16MB）
• r：8（块大小）
• p：1（并行度）

示例代码：

import scrypt from 'scrypt-js';

async function hashPassword(password, salt) {
    const key = await scrypt.scrypt(
        new TextEncoder().encode(password),
        new TextEncoder().encode(salt),
        16384,
        8,
        1,
        32 // 输出哈希长度32字节
    );
    return Array.from(new Uint8Array(key))
        .map(b => b.toString(16).padStart(2, '0'))
        .join('');
}

二、动态参数适配不同设备 #

针对移动端和PC端的性能差异，动态调整哈希参数：

• 前端初始化时，先进行一次100ms的性能探测，根据设备计算能力调整参数：比如移动端用time=3, mem=16MB，PC端提升到time=5, mem=32MB
• 后端存储哈希结果时，同时保存对应的参数（和salt一起），验证时使用相同参数，避免前端参数被篡改（可通过后端签名校验前端参数，或由后端统一下发参数）

三、辅助防护措施强化安全性 #

• 严格速率限制：后端对登录接口设置单IP每分钟最多5次尝试，多次失败后锁定账号1小时，从访问层面限制暴力破解
• 模糊错误提示：登录失败时统一提示“用户名或密码错误”，避免攻击者枚举有效用户名
• 双因素认证：对敏感账号强制开启2FA，即使密码被破解，也无法完成登录
• 智能密码引导：引导用户使用包含大小写、数字的8-12位密码，同时提供一键生成密码功能，降低记忆负担

四、避坑指南 #

• 禁止自行实现哈希算法：使用经过安全审计的成熟库，避免逻辑错误
• Pepper正确存储：Pepper应放在后端配置文件中，而非数据库，可配合AES加密哈希结果，即使数据库泄露，无Pepper也无法破解
• 前端哈希仅作辅助：前端哈希仅降低传输过程的密码泄露风险，后端必须再次用更强参数进行哈希验证

内容的提问来源于stack exchange，提问作者Anters Bear