前几天帮一个团队做代码评审看到他们把用户密码用“MD5加密”后直接落库盐还是全局写死的。我当时愣了好几秒因为他们用的就是Django而Django内置的那套密码存储策略早就把哈希算法、盐值生成、算法升级这些事安排得明明白白。这不是能力问题纯粹是大家对Django的密码存储机制只停留在“它好像加密了”的模糊印象。今天这篇就专门把Django密码存储策略彻底拆开讲透从哈希串格式到算法选型从登录校验到无感迁移一次性说完。这个内容适合谁只要是写过Django项目、或者正在为“密码到底该怎么存”纠结的后端开发者都值得花十分钟看完。看完你就不会再被“加密”还是“哈希”这类概念绕晕也能自己动手把项目的密码存储策略升级到当前推荐水准。1. 密码存储的前世今生为什么Django选择这种方案1.1 明文存储与现代哈希的对比很多人第一次接触密码存储时脑子里第一个念头就是“加密一下”。但我必须先把一个最基础、也最关键的概念掰扯清楚密码存储绝对不能使用可逆的加密算法必须使用不可逆的哈希函数。可逆加密意味着什么意味着只要拿到密钥就能把密文还原成明文。用户密码是用户自己也不可能再知道的秘密系统完全没有理由存储一个“能被解密出来的密码”。一旦数据库泄露、密钥跟着泄露所有用户的明文密码就全没了。而哈希函数是单向的理论上只能正向计算不能反向还原所以哪怕数据库整个拖走攻击者也很难直接拿到原始密码。Django的策略属于“加盐哈希”路线也就是哈希之前先拼上一段随机生成的盐值。这套方案的思路是这样的同一个密码用不同的盐产生的哈希完全不同。攻击者手里即使拿到了一份彩虹表预生成好的常见密码哈希对照表也因为盐的存在而基本失效。加盐这件事听起来简单但很多自定义代码都栽在这里要么盐值固定要么干脆不加盐等于把哈希结果直接暴露给彩虹表攻击。1.2 Django密码哈希串的解剖Django落库的密码字段并不是一长串看着没规律的乱码就完事了它内部是有完整结构的。标准格式长这样algorithm$iterations$salt$hash我随便构造一个示例pbkdf2_sha256$120000$AbC123xYz$5f6c8a9b...用$符号切成四段第一段pbkdf2_sha256是哈希算法标识第二段120000是迭代次数第三段AbC123xYz是每次生成密码时随机产生的盐值第四段是算法计算出来的最终哈希结果。为什么Django要把这些信息全部放在同一个字符串里这恰恰是它的高明之处。算法、迭代次数这些参数全部自描述这意味着Django在读这个字符串的时候可以还原出“当时的算法当时的迭代次数当时的盐值”从而完成一次完全同参数的哈希计算。哪怕你未来把默认算法从A换成了B老用户的密码字段里依然记录着算法A的信息系统随时可以校验不需要额外维护一张参数映射表。2. Django内置哈希算法面面观2.1 PBKDF2默认与稳妥Django的默认密码哈希器是PBKDF2PasswordHasher对应的算法标识是pbkdf2_sha256。PBKDF2Password-Based Key Derivation Function 2是一个应用极其广泛的标准密钥派生函数核心思想很简单对密码和盐做多次反复的哈希叠加逐轮运算把单个密码的哈希计算成本拉高到毫秒级别。这个“慢”恰恰是密码存储策略的关键。普通哈希函数如MD5、SHA1、SHA256都设计成“快”一秒钟能算几百万次攻击者暴力猜密码的代价极低。PBKDF2通过反复迭代把速度故意拖慢攻击者每猜一个密码也要付出同样的计算代价猜密码的成本立刻飙升。Django默认还会把迭代次数这个参数随着版本演进逐步上调。比如较新版本的默认迭代次数已经比老版本高出一截具体数值以当前环境的PBKDF2PasswordHasher.iterations属性为准。我强烈建议在部署时确认一下项目实际跑在哪个Django版本不要想当然沿用网上几年前的教程配置。2.2 Argon2内存困难的优势如果有人问“当前最推荐的密码哈希算法是什么”答案通常是Argon2。这个算法拿过密码哈希竞赛的冠军设计上主打“内存困难”也就是不仅计算上慢而且要求大量内存参与计算。这让它应对GPU并行暴力破解的能力比纯CPU迭代的PBKDF2更强因为一枚GPU核心的内存带宽很难共享给成千上万个并行猜测任务。Django对Argon2的支持需要额外安装argon2-cffi库然后把它加入到PASSWORD_HASHERS配置里。我自己的项目大多以Argon2为首选哈希器。选它的原因很简单现任冠军、抗GPU破解能力强、Django官方支持。唯一要注意的是部署环境需要编译或安装对应依赖在受限的云环境里偶尔会多费一点功夫。2.3 bcrypt与scrypt的实际定位bcrypt也是一个老牌密码哈希算法特点是具备内置的盐值管理但Django用的是BCryptSHA256PasswordHasher它会先把密码做一次SHA256再交给bcrypt处理。这一步是为了规避bcrypt对超长密码截断的历史问题属于Django团队做的兼容性设计。scrypt则是另一个“内存困难”思路的算法由密码学领域的权威人物提出设计上和Argon2一样重视内存占用。Django从较新版本开始也在内置哈希器列表中加入了ScryptPasswordHasher。它的好处是Python标准库本身就提供支持不需要额外安装第三方库所以环境依赖最小。2.4 算法选型怎么决策Django默认的哈希器顺序如下具体到不同版本略有差异先是PBKDF2然后是PBKDF2SHA1、Argon2、BCryptSHA256最后是Scrypt。这个顺序本质上是优先级列表存储新密码时永远优先选用列表第一个哈希器在校验老密码时则根据密码字符串里记录的算法标识取对应哈希器。如果你的项目已经引用了argon2-cffi最稳妥的做法是调整列表顺序把Argon2提到最前面。没必要强行把PBKDF2换掉PBKDF2本身就是合格方案但既然有条件上更强选项那就物尽其用。反过来如果部署环境实在装不上额外的库保留默认PBKDF2也完全能接受至少比大量老项目里的裸MD5强上好几个量级。3. 密码校验与自动升级的完整链路3.1 登录验证的核心流程当用户在Django登录表单里输入密码并提交后后端做的事情比很多人想象的要复杂。核心入口是check_password()函数它的执行链路可以拆成四步。第一步从用户表取出该用户已存储的密码哈希串解析出算法名、迭代次数、盐值和旧的哈希结果。第二步根据解析出的算法名在PASSWORD_HASHERS列表里找到对应的哈希器类。第三步用相同算法、相同盐、相同迭代次数对用户提交的明文密码重新计算一遍哈希。第四步把新算出来的哈希与数据库里存的哈希做比对如果一致说明密码正确。这里必须注意一个细节这个“比对”不是普通字符串相等比较而是采用了时间恒定比较方式比如Python标准库hmac.compare_digest。为什么要这样因为普通字符串比较遇到第一个不匹配字符就立刻返回攻击者可以通过测量响应时间猜测哈希前缀从而逐步还原完整的哈希值。时间恒定比较则无论从哪里开始不匹配都固定消耗相同时间从物理层面切断这个攻击通道。3.2 密码自动迁移机制Django做得特别漂亮的一点就是密码哈希的自动升级。当用户登录成功后Django会检查这个密码哈希是否是由当前PASSWORD_HASHERS列表里的首个哈希器生成的。如果不是比如目前列表第一位是Argon2但老密码用的是pbkdf2_sha256Django就会用Argon2重新计算密码生成新的哈希字符串然后更新到数据库。这就意味着你不用写任何额外代码也不需要让用户重新设置密码只要把配置文件里的PASSWORD_HASHERS调整好老用户在下一次登录时就会自动被迁移到新算法。这个机制是延迟且分批的不会q产生一次性迁移压力对线上系统极其友好。不过这里有一个隐形的坑如果老密码哈希使用的迭代次数与当前哈希器的默认迭代次数不一致但算法名相同Django同样会重新哈希。这带来的好处是当Django新版本上调了默认迭代次数旧密码会在用户登录时自动用更高迭代次数的参数重新生成。3.3 手动管理与批量迁移除了自动迁移Django还给了手动管理密码的工具。比如make_password()可以生成指定哈希器的新密码哈希is_password_usable()可以判断一个密码字符串是否还能正常使用。重置密码的管理命令createsuperuser、changepassword内部也都是走这套机制。如果你要做一次全员密码迁移比如从自定义的旧哈希方案换到Django标准方案单靠登录触发可能太慢。实际项目里可以写一个管理命令遍历用户表把旧哈希串转成Django兼容的新格式同时保留旧字段备份。但这种操作涉及全量用户数据改写建议优先在预发布环境演练并确保中途失败可回滚。4. 实战自定义密码哈希器与策略升级4.1 从零实现一个Hasher有时候项目会遇到历史遗留的哈希方案比如老系统用SHA256加盐、自定义了三轮迭代现在要接入Django账号体系。这时候在PASSWORD_HASHERS里加一个自定义Hasher就是最干净的解法。一个最小可用的自定义Hasher只需要继承BasePasswordHasher并实现encode()和verify()两个方法。encode()负责把明文密码变成格式化的哈希字符串verify()负责用相同盐值重新计算并比对。以“SHA256加固定策略盐”为例示意代码如下import hashlib from django.contrib.auth.hashers import BasePasswordHasher class LegacySHA256Hasher(BasePasswordHasher): algorithm legacy_sha256 iterations 1000 def encode(self, password, salt): digest hashlib.pbkdf2_hmac( sha256, password.encode(utf-8), salt.encode(utf-8), self.iterations ).hex() return f{self.algorithm}${self.iterations}${salt}${digest} def verify(self, password, encoded): algorithm, iterations, salt, _ encoded.split($, 3) reencoded self.encode(password, salt) return self.constant_time_compare(reencoded, encoded)注意verify()内部调用了constant_time_compare这就是Django提供的恒定时间比对方法千万别图省事直接用。4.2 配置PASSWORD_HASHERS的正确姿势修改密码哈希策略不是把推荐算法写进代码注释就完事真正的核心动作是配置PASSWORD_HASHERS。下面是一份推荐的配置思路PASSWORD_HASHERS [ django.contrib.auth.hashers.Argon2PasswordHasher, django.contrib.auth.hashers.PBKDF2PasswordHasher, django.contrib.auth.hashers.BCryptSHA256PasswordHasher, django.contrib.auth.hashers.ScryptPasswordHasher, ]把Argon2放第一意思是所有新密码和重设密码统一使用Argon2。后面的PBKDF2、bcrypt、scrypt保留着是为了兼容存量密码。这样即使旧密码是pbkdf2_sha256格式用户依然能正常登录并在登录后自动迁移到Argon2。还有一个关键时刻容易忽略你改了列表顺序之后务必在测试环境跑一遍完整的“老用户登录”用例确认自动迁移链路没坏。我遇到过最离谱的案例是有人把老哈希器整个从列表里删掉了结果存量用户登录直接报错因为Django找不到对应的Hasher解析哈希串。4.3 升级过程的避坑清单老项目升级密码存储策略时最容易踩的坑不是选型而是执行细节。备份数据库永远排第一。任何涉及全量用户密码哈希改写的操作都必须有完整备份并且备份要验证可以恢复不只是“备份过”这个心理安慰。别动原始字段结构。只要把密码字符串格式换成Django标准的哈希串格式就够了不要新增一张表、不要给每一行加一个算法字段Django的标准格式本身已经包含了算法信息多此一举反而增加出错概率。分批处理先灰度。如果存量用户特别多建议先用管理命令迁移一小部分账号做试点完成后再切全量。# 一个可参考的迁移命令骨架 from django.core.management.base import BaseCommand from django.contrib.auth import get_user_model User get_user_model() class Command(BaseCommand): def handle(self, *args, **options): qs User.objects.filter(password__startswithlegacy_sha256) total qs.count() for i, user in enumerate(qs.iterator(chunk_size500), 1): # 此处需要从旧哈希中解析出盐值并生成新哈希 # 实际操作时建议用 transaction.atomic 包裹 user.save(update_fields[password, updated_at]) if i % 1000 0: self.stdout.write(fmigrated {i}/{total})注意示例里需要结合实际旧格式补充解析逻辑这里只是骨架真正执行前务必打印几条记录验证输出格式与Django兼容。5. 绕不开的雷区常见问题与安全建议5.1 典型误用与修复第一个常见误用是“密码字段用可逆加密”。不少从PHP或其他语言转过来的开发者会把models.CharField里存一份AES加密后的密码。这种做法等于给攻击者留了一把钥匙。修复方式也很直接用本文介绍的标准哈希方案替换写个迁移脚本处理好存量数据。第二个误用是“自定义加密算法”。有人觉得MD5加盐不够强自己设计了一套层层嵌套的“加强版哈希”。这类方案的问题不在计算机强度而在没有经过公开密码学社区检验很容易存在未知结构性弱点。Django内置的都是经过业界多年验证的成熟算法没有必要去自研。第三个误用是“所有用户共用同一盐值”。这种写法我在不少教学项目里见过本质上等于只给口令增加了一个全局后缀彩虹表攻击者完全可以针对这个固定的盐重新生成一套彩虹表。正确的做法就是Django默认的随机盐每个用户每次生成密码都不同。5.2 常用操作排查速查表现象排查思路常见解法用户登录报错“密码格式无效”检查密码哈希串是否包含完整的四段结构确认哈希串未被截断必要时手动用make_password()重新生成改了PASSWORD_HASHERS后老用户无法登录检查老哈希算法对应的Hasher是否还在列表里把旧哈希器保留在列表后续位置不要删除登录成功但数据库哈希没有变化检查当前哈希器是否是列表第一位确认新密码确实使用了首选算法且用户是在改配置之后登录的部署环境缺少Argon2库检查argon2-cffi是否已安装优先安装依赖实在无法安装则暂用PBKDF2后续再升级5.3 安全加固的几条实用经验基于我日常碰到的真实问题和踩坑记录给出几条可以直接照做的经验。第一条密码哈希策略要和Django版本一起升级。很多人项目一跑就是好几年Django大版本完全没动。每次Django升级默认的密码哈希迭代次数都可能上调跟上升级能自动享受更强的计算成本防线。第二条不要直接往日志里打印User对象或者password字段。某些调试场景下数据敏感的字段会被完整打出来密码哈希一旦泄露到日志平台等于白干。建议写自定义日志格式时显式排除敏感字段。第三条别给用户设置密码长度上限。越长越好的密码本来就该放行。要限制的只是存储长度和展示长度哈希结果本身不管密码多长都等长所以完全没有必要为了“数据库字段长度”去限制用户输入。第四条如果项目注册时允许第三方登录绑定注意不要用同一个密码字段去混存不同体系的凭证信息。比如OAuth的access_token和密码哈希各存各的字段混在一起会让后续哈希升级逻辑复杂化。写在最后的一点心得我接触过的很多项目真正出问题的往往不是没有安全方案而是方案太陈旧。密码存储这件事选型的标准就三条算法要经过公开社区验证、要有足够高的计算成本、要支持无感升级。Django这套机制恰好把这三条都做成了默认行为。我最想提醒你的一点是密码存储策略不是“配置完就不管”的静态设置它应该跟着Django版本和硬件水平持续演进。每次升级版本之后顺手看一眼当前默认的哈希器顺序和迭代次数养成这个习惯你的用户密码存储就不会脱节太久。