【问题标题】:Is substr safe for password reset?substr 对密码重置安全吗?
【发布时间】:2014-08-19 04:43:48
【问题描述】:

我想知道使用substr(md5(rand()), 0, 17); 对密码重置链接是否足够安全?如果我要生成更长的字符串,那会更安全吗? MD5 是否安全?还是我应该做$token = sha1(uniqid($username, true));

【问题讨论】:

  • md5 可以,但rand() 很可能不行,这取决于您的srand(...)...
  • 你有什么特殊的长度限制吗,因为 sha1 和 md5 的 17 字符子集有很大的不同。
  • 只要足够安全@Jack

标签: php url encryption hyperlink md5


【解决方案1】:

substr()md5() 的使用次于rand() 的使用。

使用密码重置令牌的全部意义在于它们是不可预测的,并且由于底层 LCG 模型,rand() 被认为很弱。

使用系统的熵源会更好,例如:

$rand = openssl_random_pseudo_bytes(8); // take 8 random bytes
$token = substr(md5($rand), 0, 17);

它从系统的随机源中获取字节,例如/dev/urandom 在 Linux 或 Windows 的相应系统上。

注意,如果您没有任何特定的大小限制,您不妨选择完整的sha1() 输出并取 16 个随机字节。

此外,当您将密码重置令牌存储在数据库中时,您应该将它们视为(临时的、有时间限制的)密码;我建议将上述令牌发送给用户,然后在将它们写入数据库之前使用password_hash()。在稍后阶段,您使用password_verify() 检查给定的令牌(假设它没有过期)。

【讨论】:

  • echo $token 我得到Warning: md5() expects at most 2 parameters, 3 given in /Users/matt/Desktop/Likes/forgot/forgot.php on line 18Warning: substr() expects at least 2 parameters, 1 given in /Users/matt/Desktop/Likes/forgot/forgot.php on line 18
  • 那么这会更不可预测吗?我可以将使用过的令牌存储在数据库中并检查它们是否已被使用吗?那有必要吗?也很好的答案。
  • @user3100859 重置令牌只能使用一次然后销毁;另外,请阅读我关于重置令牌存储的答案的最后一部分。
  • 那么还要对令牌进行哈希处理然后发送吗? 30分钟也是重置令牌的公平时间吗?
  • @user3100859 另外,如前所述,如果您没有尺寸限制.. 让它变大:)
【解决方案2】:

对于随机散列,它足够安全。您的问题将是冲突,并且随机值上 MD5 的前 17 个字符应该足够随机,以避免在轻型项目中出现它们。

我会选择带有额外熵的uniqid(),而不是rand()(甚至可能是mt_rand())。

不过,我不会使用 MD5SHA1 来存储您的密码。

【讨论】:

    【解决方案3】:

    我看不出使用 substr() 的意义,除非你有某种有意义的长度限制。密钥越大越好。一般来说,使用完整形式的哈希是个好主意。如果 MD5 被认为“足够安全”被削减,那么它已经被削减了。修剪得越多,发生碰撞的机会就越大。

    我更喜欢将 GUID 用于密码重置链接。 GUID 与随机数的 MD5 散列一样有效地不可预测(且安全),它们都是 128 位值。

    确保为重置令牌使用过期时间戳。我通常使用 24 小时。

    不要使用系统时钟或任何衍生物。您要确保黑客无法重置其他用户的密码,同时记录时间戳,然后猜测重置令牌以生成重置 URL。所以不要直接使用基于系统时钟或任何其他可预测的值。

    您还应该对单个密码重置令牌使用失败/最大重试次数,就像常规登录一样,以限制可能的攻击次数。如果黑客知道用户 ID 并试图猜测密码重置 URL,您应该跟踪针对给定用户 ID 的尝试次数作为登录尝试,并相应地锁定帐户。黑客最多尝试 3 次,然后锁定帐户一个小时。在这种情况下,MD5 的 substr() 仍然非常安全。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-01-10
      • 2012-02-29
      • 2011-01-22
      • 2014-04-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多