常规安全流程之外的发布

通常情况下，我们的安全流程包括为安全预通知列表中的第三方预留一周的提前时间。但是，此流程依赖于负责任的披露实践，这些实践在协调的公开发布日期之前会维护安全问题的机密性。为促进这一点，我们要求潜在的安全问题始终通过电子邮件报告给security@djangoproject.com，而不是通过公共渠道，例如 Django 的工单跟踪器或 django-developers 邮件列表。

不幸的是，这个问题无法通过我们的常规流程处理，因为它首先在 django-developers 邮件列表上公开报道。Django 核心团队已对此进行了确认，并且由于问题已公开且可能影响 Django 的实时部署，因此我们立即发布安全版本。

问题：通过大型密码进行拒绝服务攻击

Django 的身份验证框架——django.contrib.auth——包含一个默认的用户模型和后端，通过用户名和密码进行身份验证。原始密码不会存储在数据库中；而是存储密码的哈希版本，并且每次用户尝试登录时都会计算哈希值。要使用的哈希器可通过PASSWORD_HASHERS设置进行配置。

Django 中的默认密码哈希器是 PBKDF2，它的优点是可以有效地任意提高计算哈希的复杂性，方法是在生成最终结果之前重复应用“轮数”。这增加了使用蛮力方法计算许多可能的明文值的哈希值的攻击的难度，这些攻击希望能发现哪个明文密码对应于给定的哈希值。

不幸的是，这种复杂性也可以用作攻击媒介。Django 对明文密码的长度没有任何限制，这意味着攻击者可以简单地提交任意大的（并且保证失败的）密码，迫使运行 Django 的服务器执行由此产生的昂贵的哈希计算以尝试检查密码。例如，大小为 1 MB 的密码使用 PBKDF2 哈希器进行检查大约需要一分钟的计算时间。

这允许通过重复提交大型密码来进行拒绝服务攻击，从而在昂贵的相应哈希计算中占用服务器资源。

虽然这对于设计为计算速度相对“慢”的算法（例如 PBKDF2（再次强调，它是 Django 身份验证框架中的默认哈希器））最有效，但它对其他哈希器也有效，因为计算哈希的时间通常会随着密码的大小而增长。

为了解决这个问题，Django 的身份验证框架现在将自动拒绝任何超过 4096 字节的密码的身份验证。

受影响的版本

• Django 主开发分支
• Django 1.6（目前处于测试版状态）
• Django 1.5
• Django 1.4

在撰写本文时，正在努力为这个问题获取 CVE。一旦获得 CVE，本帖将更新。

更新：此问题已分配 CVE-2013-1443。

解决方案

已将补丁应用于 Django 的主开发分支以及 1.6、1.5 和 1.4 发布分支，这些补丁解决了上述问题。可以从以下变更集直接获取这些补丁

• 主开发分支
• 1.6 发布分支
• 1.5 发布分支
• 1.4 发布分支 和 针对 Python 2.5 兼容性的附加提交

已发布以下新版本

• Django 1.6 beta 4（下载 Django 1.6b4 | 1.6b4 校验和）
• Django 1.5.4（下载 Django 1.5.4 | 1.5.4 校验和）
• Django 1.4.8（下载 Django 1.4.8 | 1.4.8 校验和）

关于安全报告的常规说明

与以往一样，我们要求潜在的安全问题通过私人电子邮件报告给security@djangoproject.com，而不是通过 Django 的 Trac 实例或 django-developers 列表。如果您认为您可能发现了一个安全问题但不确定，我们强烈建议您谨慎行事，通过电子邮件而不是公共渠道进行报告。请参阅我们的安全策略以获取更多信息。