使用已经哈希的密码和Django的密码哈希

时间:2013-03-05 23:37:56

标签: django django-authentication

我有一个API,设备通过身份验证来接收有时间限制的身份验证令牌。这些设备将有一个“记住我的密码”复选框,因此这种身份验证可以自动进行。

我不打算在设备上以明文形式存储用户密码。

我无法将令牌过期时间延长,因为这些设备是表现性的和面向客户的。最终,令牌将在与客户的时间内到期,并且设备将无法发出请求或必须弹出身份验证对话框。这有可接受的解决方法(例如令牌最近2天;每天早上需要reauth)但我首先想看看避免将这种复杂性暴露给设备的选项。

我想尝试在设备上以密码和散列形式存储密码 1 。此哈希密码将在auth请求中提交。在服务器端,API auth依赖于Django的contrib.auth。传统的密码工作流是散列请求密码并将其与存储的散列进行比较。由于我有一个已经散列的请求密码,因此在比较之前我需要重新 - 清除存储的密码。

我尝试了这个解决方案,但似乎需要修改每个密码哈希。我仍然需要在网站的非API部分支持标准密码身份验证,因此我最终会为我想要使用的每个哈希算法使用双倍哈希:BCryptPasswordHasher / PreHashedBCryptPasswordHasher等等。实际上现在只想使用一个,这不是我想留给另一个开发人员在尝试添加或更改一个哈希时必须弄明白的场景。

实现“预先散列”的另一个选择是修改django.contrib.auth,但我不想保留它的分支。

我确定其他人之前已经解决了这个问题。我正在寻找具体的建议,关于我如何找到一个单点来实现预先调整的密码比较,而不需要经常比较,并提供有关解决方案的建议。如果你有一种解决安全问题并且合理的替代方法,我会很高兴听到它。

干杯

  1. 这不会阻止顽皮的人通过对API进行身份验证来访问哈希,但它会保护在许多网站上使用一个密码的用户不会被更广泛地暴露。

1 个答案:

答案 0 :(得分:1)

让我看看我是否理解你的意图。您有一个API,您可以使用令牌进行身份验证。令牌是在会话开始时通过密码验证获得的。您希望启用一种“记住”密码的方法,以便用户不必每次都登录,如果这是他们喜欢的,但您不希望在设备中以明文形式存储密码。这是对的吗?

实现这一目标的最简单方法是,如果用户选择“记住我”,则使令牌成为永久性或具有很长的到期时间。这样,您就可以在设备上存储非密码的身份验证形式。

只要您还执行以下操作,这应该可以正常工作:

  • 当用户更改密码时,无效服务器端的所有令牌。
  • 为每个设备生成令牌,向用户显示使用可在其个人资料中撤消的令牌的应用列表。

如果你加密哈希密码,你基本上是在创建一个令牌,但更糟糕的是因为它与密码相关联,如果令牌被泄露,则必须更改密码。