为什么Python的Django默认密码哈希算法升级到了Argon2？-Python教程-PHP中文网

django默认密码哈希算法仍是pbkdf2+sha256，因其零依赖、nist合规、迭代与salt可扩展，且默认26万次迭代兼顾安全与性能；argon2虽被支持但非默认，需手动配置并承担内存、延迟与运维风险。

为什么python的django默认密码哈希算法升级到了argon2？

Django 默认密码哈希算法**没有升级到 Argon2**——截至 2026 年 9 月，它仍默认使用 PBKDF2PasswordHasher（即 PBKDF2 + SHA256），PASSWORD_HASHERS[0] 仍是 django.contrib.auth.hashers.PBKDF2PasswordHasher。 Argon2 虽然被 Django 支持（在 PASSWORD_HASHERS 列表中排第三），但它**不是默认存储算法**，也不会自动替换已有 PBKDF2 密码，除非你显式修改配置并触发重哈希。下面说清楚几个关键点：

为什么 Argon2 在 Django 中“存在但不默认”？

Argon2 是 2015 年密码哈希竞赛冠军，抗 GPU/ASIC 更强，但它的落地依赖第三方库 argon2-cffi。Django 坚持“零依赖开箱即用”，而 hashlib.pbkdf2_hmac 是 Python 标准库原生支持的。只要没强制要求 Argon2 的合规场景（如某些金融或政务审计明确指定 Argon2id），Django 就不会把有依赖的算法设为默认。

Django 中启用 Argon2 的真实成本是什么？

启用后不是“更安全就完事了”，你要面对这些实际约束：

Python数据分析(免费版)

提供Python数据清洗、统计分析与可视化建议，覆盖业务报表与科研数据的快速处理流程。

下载

argon2-cffi 必须安装，且版本需匹配：2026 年主流是 argon2-cffi==23.3.0，旧版可能触发 argon2.exceptions.HashingError: out of memory
内存参数 m_cost 设太高（比如 > 1024 MB）会导致容器 OOM —— 这不是理论风险，而是 2023 年 GDPR 罚款案例（EDPB-2023-087）的直接原因
Argon2 的验证耗时波动大：同一台机器上，m_cost=64, t_cost=3, p_cost=2 下，验证一个密码可能从 80ms 到 320ms 不等，对登录 P99 延迟敏感的服务要实测压测
Django 不会自动将旧 PBKDF2 密码升级为 Argon2；必须靠用户下次登录时调用 make_password() + 自定义逻辑触发重哈希

什么时候该主动把 `PASSWORD_HASHERS[0]` 换成 Argon2？

只在满足以下全部条件时才建议切换：

你的部署环境能稳定提供 ≥ 1GB 可分配内存给单次哈希（注意：不是总内存，是 per-hash 峰值内存）
你已接入密码泄露检测（如 HaveIBeenPwned API 钩子），且能对新注册/改密用户强制走 Argon2
你有配套的渐进式迁移策略：比如用 CryptContext（来自 Passlib）做双算法兼容，或在 Django 的 authenticate() 中手动 fallback 验证
你的合规文档（如等保三级、GDPR 数据处理协议）明文要求“使用内存硬性哈希算法”，而非“推荐”或“支持”

真正容易被忽略的是：算法本身只是链条一环。PBKDF2 默认 260000 次迭代在 2026 年仍有效，验证耗时约 100ms；而一个配置失误的 Argon2（比如 m_cost=2048 在 2GB 内存的 Kubernetes Pod 里）可能让登录接口直接超时熔断——安全不是换算法，是换算力预算、换运维水位、换风险认知。