不要存储明文密码，也不要自己发明加密方式。安全存储用户密码的核心是：使用强哈希算法 + 唯一随机盐值 + 足够的计算成本。
用 Argon2 或 BCrypt，而不是 MD5、SHA1、SHA256
MD5、SHA 系列是快速哈希，专为校验文件设计，不适合密码——它们跑得太快，容易被暴力破解或查表攻击。现代推荐：
Argon2（目前 NIST 推荐的首选）：抗 GPU/ASIC 攻击，可调内存、时间、并行度 BCrypt：成熟稳定，.NET 有高质量实现（如BCrypt.Net-Next），自带盐生成和验证逻辑 如果必须用 .NET 内置方案，
Rfc2898DeriveBytes（即 PBKDF2-HMAC-SHA256）可用，但安全性弱于前两者
盐（Salt）必须唯一、随机、每次生成
盐不是密钥，不需要保密，但必须满足两个条件：每用户独立 + 密码哈希前由密码学安全随机数生成器产生（如
RandomNumberGenerator）。 ❌ 不要复用同一盐值，不要用用户名、ID、固定字符串当盐 ✅ 盐长度建议 ≥ 16 字节；BCrypt 自动处理盐，Argon2 推荐 16–32 字节 盐可以和哈希值一起存数据库（比如拼成
$argon2id$v=19$m=65536,t=3,p=4$...$...这种标准格式），无需额外字段加密
哈希结果要带参数、可验证、防篡改
只存一个“哈希字符串”不够。必须同时记录算法、参数（如迭代次数、内存大小）、盐和输出——否则未来无法升级或验证。
用标准格式序列化：Argon2 推荐使用 Argon2.NET 的Hash方法，它默认输出符合 IETF RFC 9106 的 Base64 编码字符串 BCrypt 使用
BCrypt.Net-Next的
HashPassword，返回含盐和参数的单字符串（如
$2a$12$...） 验证时直接传入原始密码和完整哈希字符串，库自动提取盐与参数完成比对
别忽略验证流程与防御时机
哈希只是存储环节。真实系统中还需注意：
登录时统一用恒定时间比较（BCrypt.Verify或
Argon2.Verify已内置，勿用
==） 对频繁失败的账号做限速（如滑动窗口计数器），防暴力撞库 前端可加简单密码强度提示，但绝不前端哈希——服务端仍需重新哈希，否则等于放弃服务端防护 定期审计：检查是否还有旧算法遗留（如 SHA1 存储的密码），迁移时采用“懒更新”策略（用户下次登录时重哈希）
基本上就这些。核心不是“怎么写代码”，而是“选对工具+拒绝捷径”。用成熟库、走标准流程、让盐和参数随哈希一起落库——安全就落在细节里。
