【问题标题】:Hash from "email+salt " as a token to verify email来自“email+salt”的哈希作为验证电子邮件的令牌
【发布时间】:2011-11-08 17:16:04
【问题描述】:

我正在验证用户电子邮件地址。
大多数人告诉的方式是创建一些独特的令牌将其存储在数据库中并 发送给用户。

我只是用全站范围的盐来散列(sha256)电子邮件地址
并将此哈希发送给用户。

我是否遗漏了什么或者这足以验证?

【问题讨论】:

  • 电子邮件或电子邮件地址? (您只是在确认用户的电子邮件地址吗?)
  • 电子邮件地址 - 只是确认
  • 有关您使用它的上下文的更多信息会有所帮助。正如所写,似乎第三方可以拦截一封发给用户的包含令牌的电子邮件,然后使用带有欺骗性发件人地址的令牌来回复一封可以验证但不是来自实际用户的电子邮件。

标签: salt email-validation sha256 sha saltedhash


【解决方案1】:

有几件事可能值得一看(或不值得一看)。

如果有人发现了您的盐,那么他们可以重建您的哈希并淹没您的系统。在这种情况下,您需要确保用户请求将他们的电子邮件地址添加到您正在创建的任何内容中。 (也就是说,我不会完全摆脱将哈希存储在数据库中。)

另外,如果盐是相同的,如果他们再次从同一个电子邮件地址请求,哈希值将是相同的。您是否希望每次发出请求时都使用不同的哈希值,即使是相同的电子邮件地址?您可以在散列之前将服务器日期/时间连接到电子邮件地址以使其每次都不同。

【讨论】:

  • 添加日期时间还有一个额外的好处,即您可以使用它在某个设定时间后“过期”令牌......比如 24 小时。
  • @hatchet:我几乎写进去了。:)不能通过在数据库中记录请求时间来完成过期吗?
  • 你是对的。我在考虑加密/解密,而不是匹配散列值。
【解决方案2】:

你可以这样做,如果没有人得到服务器端的盐,那就省了。归根结底是邮箱验证,如果你因为法律原因不需要做,没必要让它变得更复杂。

但这取决于你的目标。是否希望它更加安全?您想易于实施吗?你想要它易于维护吗?您是否在考虑脚本的执行时间?

顺便说一句:在电子邮件中包含长链接时有一件非常讨厌的事情:可能有电子邮件科学家会破坏您的链接,因此可以将代码与链接一起添加,如果代码未通过链接完全传输,请用户可以在其中添加代码的表单。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-02-13
    • 2022-12-30
    • 2014-10-07
    • 2022-11-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-11
    相关资源
    最近更新 更多