我有一个API，设备根据它进行身份验证以接收有时间限制的验证令牌。这些设备将有一个"记住我的密码"复选框，因此身份验证可以自动进行。
我不打算在设备上明文存储用户密码。
我不能使令牌过期时间长，因为设备是演示和面向客户的。最终，令牌会在客户使用期间过期，设备要么无法发出请求，要么必须弹出一个验证对话框。对此有一些可接受的解决方案(例如令牌持续2天;每天早上都需要真实)，但我想先看看避免将这种复杂性暴露给设备的选项。
我想尝试在设备上以盐渍和散列形式存储密码1。该散列密码将在身份验证请求中提交。在服务器端，API的认证依赖于Django的contrib.auth。传统的密码工作流程是对请求密码进行散列，并将其与存储的散列进行比较。因为我有一个已经散列的请求密码，所以我需要在比较之前对存储的密码进行re散列。
我尝试了这个解决方案，但它似乎需要修改每个密码散列器。我仍然需要在站点的非api部分支持标准密码验证，所以我最终会为我想使用的每个哈希算法使用双倍哈希:BCryptPasswordHasher/PreHashedBCryptPasswordHasher等。虽然我现在只想使用一个散列器，但我不想让其他开发人员在尝试添加或更改散列器时弄清楚这种情况。
另一个实现"预哈希"的选项是修改django.contrib。是的，但是我不希望维护它的分支。
我确信其他人以前已经解决了这个问题。我正在寻找关于如何在不削弱常规比较的情况下找到单个点来影响预散列密码比较的具体建议，以及关于一般解决方案的建议。如果你有另一种既能解决安全问题又合理的方法，我会很高兴听到的。
欢呼- 这不会阻止访问哈希的不法分子对API进行身份验证，但它会保护在许多网站上使用一个密码的用户免受更广泛的暴露。
让我看看我是否理解你的意图。您有一个API，可以使用令牌对其进行身份验证。令牌在会话开始时通过密码身份验证获得。你想启用一种"记住"密码的方法，这样用户就不必每次都登录，如果他们喜欢的话，但你不想在设备中以明文形式存储密码。对吗?
实现这一点的最简单方法是使令牌永久或有一个很长的到期，如果用户选择"记住我"。这样你就可以在设备上存储一种身份验证形式，而不是密码。
只要您还执行以下操作，这应该可以正常工作:
- 当用户修改密码时，服务器端所有令牌失效
- 为每个设备生成令牌，向用户展示使用令牌的应用程序列表，这些令牌可以在他们的配置文件中被撤销。
如果你对密码进行双哈希，你基本上是在创建一个令牌，但更糟糕的是，因为它与密码相关联，如果令牌被泄露，密码将不得不更改。