不能直接用md5或sha256存密码，因其是快速哈希函数，易被gpu暴力破解；bcrypt通过可调工作因子实现“故意慢”，大幅增加攻击成本。
为什么不能直接用 MD5 或 SHA256 存密码
因为这些是快速哈希函数，现代 GPU 一秒能跑几亿次——撞库、查表、爆破都太容易。哪怕加了盐（salt），只要算法快，攻击者就能穷举。BCrypt 的核心价值在于「故意慢」：它内置可调的工作因子（workFactor），让单次哈希耗时在毫秒级，极大拖慢暴力尝试速度。
常见错误现象：
— 把用户明文密码存进数据库（连哈希都不做）
— 用 Convert.ToBase64String(SHA256.Create().ComputeHash(...)) 当“加密”
— 自己拼接字符串加盐再哈希（盐没随机、没存、没绑定用户）
实操建议：
— 直接弃用所有自研哈希逻辑
— 使用成熟库，盐由 BCrypt 自动生成并和哈希结果一起编码输出（单个字符串含 salt + hash + workFactor）
— 工作因子选 12（当前推荐值；10 太快，14 在高并发登录场景可能拖慢响应）
如何用 BCrypt.Net-Next 正确哈希与验证密码
BCrypt.Net-Next 是目前最活跃、.NET 5+ 友好、修复了旧版线程安全问题的分支。别用已归档的 BCrypt.Net（v3.x 及以前）。
安装命令：dotnet add package BCrypt.Net-Next
哈希密码（注册/改密时）：string hash = BCrypt.HashPassword(plainTextPassword, Bcrypt.GenerateSalt(12));
更简洁写法（推荐）：string hash = BCrypt.HashPassword(plainTextPassword, 12);（内部自动生盐）
验证密码（登录时）：bool isValid = BCrypt.Verify(candidatePassword, storedHash);
注意：storedHash 是上一步生成的完整字符串（含 salt 和 workFactor），不需要单独存 salt 字段。
关键点：
— Verify 会自动解析 storedHash 中的 salt 和 workFactor，无需手动提取
— 不要对哈希结果再 Base64 编码或二次加密——BCrypt 输出已是可存储的 ASCII 字符串（形如 a$...）
— 若验证始终返回 false，先检查是否误把哈希值当明文传给了 Verify
BCrypt 在 .NET 中的兼容性与性能边界
.NET Framework 4.6.1+、.NET Core 2.0+、.NET 5/6/7/8 全支持。但要注意：
— BCrypt.HashPassword 是同步阻塞调用，别在 ASP.NET Core 的 Controller 同步方法里直接用（尤其高并发时）
— 它不提供异步 API，所以必须包裹在 Task.Run 中实现非阻塞（仅限必要场景）：await Task.Run(() => BCrypt.HashPassword(pwd, 12));
性能参考（i7-10870H，.NET 6）：
— workFactor=12：平均 ~150ms/次哈希
— workFactor=13：~300ms
— 登录接口若每秒处理 50 次请求，workFactor=13 就可能引发线程池饥饿
实操建议：
— 生产环境统一用 12，后续升级可批量重哈希（见下一条）
— 不要在 DTO 或日志中打印完整 storedHash（虽不可逆，但属敏感凭证）
— 数据库字段类型用 nvarchar(255)（BCrypt 最长输出约 60 字符，留余量）
如何安全升级已有的弱哈希密码（比如从 SHA256 + 固定盐 迁移）
不能强制所有用户改密码。正确做法是「懒迁移」：用户下次登录时，用旧逻辑验证成功后，立刻用 BCrypt.HashPassword 生成新哈希，覆盖原存储值。
伪代码逻辑：
if (legacyVerify(inputPwd, db.StoredLegacyHash)) {<br> db.StoredHash = BCrypt.HashPassword(inputPwd, 12);<br> db.HashMethod = "bcrypt";<br> db.Save();<br>}
容易踩的坑：
— 忘记标记哈希方式（后续无法区分该用哪种逻辑验证）
— 在验证失败时也执行重哈希（等于帮攻击者把任意输入转成有效 BCrypt 哈希）
— 把旧盐硬编码在代码里，导致无法在不同环境复现验证逻辑
补充提醒：BCrypt 本身不防彩虹表，但它的 salt 是每次随机且内嵌在输出中，天然隔离用户间碰撞；真正危险的是「全局固定 salt」或「无 salt」——这两类存量数据必须优先清理。
