【问题标题】:Sanitizing passwords for password_hash()清理 password_hash() 的密码
【发布时间】:2018-08-21 02:05:57
【问题描述】:

我正在阅读使用password_hash() 时的空字节问题。这给了我两个问题:

  • 从 PHP7 开始,空字节漏洞是否仍然存在? 我尝试使用 password_hash() 来复制它,但要么它已修复,要么我无法复制它。当\0 后面的字符不同或不存在时,password_verify() 返回 false。
  • 还有其他警告在处理密码时我应该注意什么?我不想对它们本身进行清理(用户需要确保处理后的密码字符串正是他们发送的内容),但我看到了这样的代码(再次,vs null-bytes):str_replace(chr(0), '', $input)。处理密码时我应该使用它吗?我也应该使用其他东西吗?

【问题讨论】:

  • bcrypt 也有 72 个字节的硬限制,任何更多的内容都会被有效截断。如果您使用的是 PHP>=7.2,则可以使用不受这些问题影响的新 Argon2i 哈希。
  • 虽然我通常反对以任何方式更改密码输入,但考虑到它们对 bcrypt 的影响,我认为删除 NUL 字节并不是你能做的最糟糕的事情。更不用说你真的必须搞砸王室才能让他们在你的密码中摆在首位。
  • 我什至不会对其进行消毒。只需测试一个 NULL 字节(如 strpos),如果为真则中止。

标签: php security passwords password-hash


【解决方案1】:

你可以用这个来测试

$hash = password_hash("\x00 abc", PASSWORD_DEFAULT);
var_dump(password_verify("\x00 foo", $hash)); // true ???

但是当从 ie 表单提交密码时,您会收到字符串“\x00 密码”,它不会像“\x00 密码”那样插入(单引号和双引号)。

$hash = password_hash("\x00 abc", PASSWORD_DEFAULT);
var_dump(password_verify('\x00 foo', $hash)); // false!

【讨论】:

  • 谢谢。我试过你所说的,它似乎是正确的。此外,正如@Sammitch 所说,使用 Argon2i 哈希也不再是问题。因此,我将完全保留用户提交的密码。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2023-03-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-04-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多