开发者必知的密码安全实践

永远不要自己实现密码哈希

密码安全中最危险的反模式之一是开发者自行实现密码哈希算法。常见的错误包括：使用MD5或SHA-1（速度太快，适合文件完整性校验但不适合密码存储）；不加盐的哈希（对彩虹表攻击毫无防御）；使用现成加密库的通用哈希功能（未针对密码存储场景优化）；实现自定义的"更安全"方案（几乎必然存在设计缺陷）。

正确的做法是使用专为密码存储设计的算法库。这些算法（bcrypt、Argon2、scrypt、PBKDF2）的设计目标是故意"慢"，通过增加计算时间和内存需求来抵御GPU破解。作为开发者，你的工作是选择正确的算法并正确配置参数，而不是自己实现它。

2025年推荐的密码哈希算法

各主要语言和框架的推荐实现：

# Python - 使用 bcrypt
import bcrypt
# 哈希
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
# 验证
bcrypt.checkpw(password.encode(), hashed)

# Python - 使用 Argon2（推荐用于新项目）
from argon2 import PasswordHasher
ph = PasswordHasher()
hashed = ph.hash(password)
ph.verify(hashed, password)  # 验证

# Node.js - 使用 bcrypt
const bcrypt = require('bcrypt');
const hashed = await bcrypt.hash(password, 12);  // cost factor=12
await bcrypt.compare(password, hashed);  // 验证

# Go - 使用 golang.org/x/crypto/bcrypt
import "golang.org/x/crypto/bcrypt"
hashed, _ := bcrypt.GenerateFromPassword([]byte(password), 12)
bcrypt.CompareHashAndPassword(hashed, []byte(password))

# PHP - 使用内置函数（PHP 5.5+）
$hashed = password_hash($password, PASSWORD_ARGON2ID);
password_verify($password, $hashed);

算法选择建议：新项目首选 Argon2id（NIST推荐，抗GPU和侧信道攻击）；需要广泛支持的场景使用 bcrypt（work factor 12或以上）；绝对不要在新项目中使用 MD5、SHA-1 或未加盐的 SHA-256/SHA-512。

密码策略设计：遵循 NIST 新规范

基于 NIST SP 800-63B，现代密码策略应该：要求最小长度（至少8位，推荐12位以上）；支持最大长度至少64位（不要限制在20位或更短）；支持所有Unicode字符（包括表情符号、中文字符、空格）；不要强制要求特殊字符、大小写混合（这些规则会适得其反）；不要强制定期更换密码（除非检测到泄露）；检查密码是否出现在已知泄露列表中（可集成Have I Been Pwned API）。

特别说明密码最大长度的问题：一些开发者认为限制密码长度（如256位）可以防止拒绝服务攻击（通过提交超长密码消耗哈希计算资源）。这是一个合理的担忧。解决方案是在哈希前对密码进行截断（如取前72个字节），或者设置合理的上限（如1024位）并在输入验证时处理超长输入，而不是限制用户到更短的密码。

安全的密码重置流程设计

密码重置是认证系统中最容易出现安全漏洞的环节之一。安全的密码重置流程要点：使用高熵的一次性令牌（使用CSPRNG生成，而不是用户ID或时间戳）；设置短暂的过期时间（15-60分钟，而不是24小时甚至永不过期）；一次性使用（使用后立即使令牌失效）；使用后记录安全日志；不要在URL或邮件中明文传输密码；不要通过邮件发送新密码（发送重置链接，让用户自行设置新密码）。

一个常见的错误是使用"安全问题"作为密码重置的验证方式（宠物名、出生城市等）。这些问题的答案通常可以从公开信息或社会工程学中获取，安全性极低。现代做法是使用邮件或短信发送的一次性令牌，配合TOTP认证器，而不是依赖安全问题。

防止密码相关的常见漏洞

开发者需要主动防范以下密码相关漏洞：时序攻击（Timing Attack）：在密码比较时使用固定时间比较函数（如 hmac.compare_digest() 或 bcrypt.checkpw()），而不是普通字符串比较；SQL注入：始终使用参数化查询，不要将密码或用户名拼接到SQL语句中；在传输过程中泄露密码：确保所有密码相关接口只通过HTTPS传输，HTTP Strict Transport Security (HSTS) 头部应该被设置；在日志中记录密码：审查所有日志记录代码，确保密码字段、Authorization头部、Cookie不会出现在日志文件中。

还有一个经常被忽视的风险：在内存中长时间保持密码的明文副本。在处理完密码后（哈希或验证），应该尽快清除包含密码的变量。某些语言（如Java、Python）对不可变字符串的内存管理使得这更难做到，但在高安全性场景中仍然值得关注。

实施多因素认证

无论密码存储做得多好，都应该为用户提供（并鼓励使用）多因素认证。对于大多数应用，TOTP（基于时间的一次性密码）是最佳选择：广泛的认证器应用支持（Google Authenticator、Authy）；不依赖电话网络（SMS有SIM卡劫持风险）；标准化（RFC 6238），易于集成。实现TOTP可以使用现有库，如Python的 pyotp、Node的 speakeasy，或框架级别的解决方案。

如果你的应用面向企业用户，支持 WebAuthn/FIDO2（硬件安全密钥，如YubiKey）将提供最高级别的安全性，同时也是应对钓鱼攻击的唯一可靠防御手段。WebAuthn 已经得到所有主流浏览器的原生支持，实现成本比五年前低得多。

密码与机密信息管理

作为开发者，你不仅需要保护用户密码，还需要管理应用程序本身使用的机密：数据库密码、API密钥、加密密钥、OAuth客户端密钥等。这些机密应该通过专门的密钥管理服务（KMS）或密钥存储系统（如HashiCorp Vault、AWS Secrets Manager、GCP Secret Manager）管理，而不是硬编码在配置文件或源代码中。

在本地开发环境中，使用 .env 文件存储机密（确保在 .gitignore 中排除），并通过 dotenv 等库加载到环境变量中。在CI/CD流水线中，使用平台提供的加密环境变量（如GitHub Secrets、GitLab CI Variables）而不是在配置文件中硬编码。在生产环境中，使用上述专业的密钥管理服务。