生成重置密码令牌的最佳做法

Jus*_*tin 22 passwords guid reset-password

关于如何构建重置密码令牌的最佳实践?我在想:

随机17个字符[a-zA-Z0-9] +全局唯一id +随机17个字符[a-zA-Z0-9].

是否有更好的解决方案,或重置密码令牌的行业标准?

mar*_*kli 38

有一些重要的要点需要考虑.

  1. 代码应该是随机的(从MCRYPT_DEV_URANDOM读取),不应该从其他用户相关信息中获取.
  2. 理想情况下,代码是base62编码的(AZ az 0-9),以避免Url出现问题.
  3. 在数据库中存储令牌的哈希值,否则对数据库具有读访问权限的攻击者可以重置任何帐户.

这导致了在用户单击链接后必须在数据库中找到令牌的哈希的问题.存储令牌有两种可能的方法:

  • 您使用SHA512之类的哈希算法对令牌进行哈希处理,而不使用盐.如果令牌非常强大(最小长度为20且0-9 az AZ),则这是安全的.从理论上讲,在将数据输入数据库之前,必须检查这种哈希是否已经存在,实际上这可以忽略不计.我实现了一个可以处理这些令牌的密码重置类.
  • 您使用BCrypt和salt散列令牌.这允许更短的令牌,但您无法在数据库中搜索散列令牌.相反,您必须在链接中包含row-id才能找到令牌.

  • 有关[存储在数据库中时密码重置令牌是否应该进行哈希处理的更多信息?](http://security.stackexchange.com/questions/86913/should-password-reset-tokens-be-hashed-when-stored-in-一个数据库).另请注意,您的重置令牌**应该到期**. (4认同)
  • @DustinRasener - 获取对数据库的写访问权限比只读访问权限要困难得多.使用SQL注入,丢弃备份,使用已部署的服务器可以获得读访问权限......另一方面,如果攻击者有权写入数据库,他不需要重置密码,他只需覆盖密码哈希直接. (2认同)