password_hash()出于多种原因，您永远都不应逃脱，修整或使用任何其他清理机制来对将使用PHP进行哈希处理的密码，其中最大的一个原因是，对密码进行额外的清理需要不必要的额外代码。

您将争论不休（并且您会在接受系统使用用户数据的每篇文章中看到它），我们应该清除所有用户输入，并且您将接受我们从用户那里接受的所有其他信息。密码不同。
哈希密码不能提供任何SQL注入威胁，因为在将字符串存储到数据库之前将其转换为哈希。

散列密码的行为是使密码安全地存储在数据库中的行为。哈希函数对任何字节都没有特殊的含义，因此出于安全原因，不需要清理其输入

如果您遵循允许用户使用他们想要的密码/短语的口号，并且不限制密码，允许任何长度，任何数量的空格和任何特殊字符的散列，将使密码/密码安全，无论其中包含什么内容。密码。到目前为止，最常见的哈希（默认值）PASSWORD_BCRYPT将密码转换为60个字符的字符串，其中包含随机盐以及哈希密码信息和开销（创建哈希的算法开销）：

PASSWORD_BCRYPT用于使用CRYPT_BLOWFISH算法创建新的密码哈希。这将始终导致使用“ $ 2y
$”加密格式的哈希，该哈希格式始终为60个字符。

由于向函数添加了不同的哈希方法，因此存储哈希值的空间要求可能会发生变化，因此，对于存储的哈希值，最好在列类型上加大，例如VARCHAR(255)或TEXT。

您可以使用完整的SQL查询作为密码，并且会对其进行哈希处理，从而使SQL引擎无法执行该查询，例如，

SELECT * FROM `users`;

可以哈希到 $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

让我们看看不同的清理方法如何影响密码-

密码为I'm a "dessert topping" & a <floor wax>!（密码末尾有5个空格，此处未显示。）

当我们使用以下修整方法时，会得到一些不同的结果：

var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));

结果：

string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>!     " // escape characters have been added
string(34) "I'm a "dessert topping" & a !     " // looks like we have something missing

当我们将这些发送到时会发生什么password_hash()？就像上面的查询一样，它们都被散列了。当您尝试验证密码时出现问题。如果我们采用这些方法中的一种或多种，​​则必须先重新使用它们，然后再与比较password_verify()。以下内容将失败：

password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query

您必须通过选择的清除方法来运行发布的密码，然后才能在密码验证中使用该密码的结果。这是不必要的步骤，会使哈希变得更好。