在自定义电子邮件中发送未散列的设计 reset_password_token答案

【问题标题】：Sending unhashed Devise reset_password_token in custom email在自定义电子邮件中发送未散列的设计 reset_password_token
【发布时间】：2016-12-19 19:05:49
【问题描述】：

我在我的 Rails 4.2 应用程序中使用 Devise 3.5。我已经用自定义 HTML 电子邮件覆盖了所有库存电子邮件。由于我设计电子邮件传递代码的方式，电子邮件模板不可能访问令牌的散列版本，例如reset_password_token。

我遇到的问题是电子邮件模板只能访问存储在数据库中的未哈希令牌。我尝试在我的电子邮件模板中使用数据库中未散列的令牌，但是当用户单击该链接时，Devise 的PasswordsController#update 会调用resource_class.reset_password_by_token(resource_params)。 Devise::Recoverable 然后取消哈希令牌并尝试找到用户。这会失败，因为未散列的令牌与数据库中的令牌不匹配（因为该令牌开始时已经未散列）。

我的问题分为三个部分：

在电子邮件（例如密码重置电子邮件）中发送未经哈希处理的令牌有哪些安全隐患？
我假设发送未散列的令牌是个坏主意。如果是这样，我可以通过覆盖PasswordsController#create 来解决这个问题，以便我可以拦截散列和未散列的令牌并将两者都保存到数据库中，从而使我的邮件代码可以使用散列的令牌？在尝试这种方法之前，我应该注意哪些安全隐患？
有什么方法可以在呈现我的电子邮件模板之前获取未散列的令牌并对其进行散列，这样我就可以避免将其保存到数据库等变通方法？

【问题讨论】：

标签： ruby-on-rails devise devise-recoverable

【解决方案1】：

您的假设不正确。未散列的令牌在电子邮件中发送是安全的，但在数据库中存储是不安全的。这样一来，有权访问您的数据库的人就无法重建密码重置 URL。

因此，您希望电子邮件只能访问未散列的令牌。

如需更详细的讨论，请参阅http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/上的“在数据库中存储消化的令牌”

【讨论】：

我明白了，所以我混淆了散列与未散列。我仍然有同样的问题。缩短的（未散列的）令牌应该在电子邮件中，因为 Devise 会尝试对其进行散列，然后将输出与数据库中的内容进行匹配。
编辑链接到参考文献
它应该在视图中可用@token，但是你说你重新设计了它，所以在不知道你重新设计的细节的情况下，我不能说你如何让@token进入您需要的范围
对，@token 在我的电子邮件代码范围内不可用，因为电子邮件代码是一项后台作业，旨在处理许多不同类型的电子邮件，而不仅仅是设计电子邮件。
当您排队作业时，您需要传递@token。这显然不是理想的，因为它违背了将@token 排除在数据库之外的目的，因为它仍然以其未散列的形式存在于您的数据库或您的 redis 服务器上（取决于哪个后端 ActiveJob 正在使用）。然而，它的存在时间要短得多——只要足够长的时间让作业出队并发送电子邮件，而不是直到用户点击电子邮件中的密码重置链接。