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 missingstring(65) "I'm a "dessert topping" & a <floor wax>! " // double quotes, ampersand and braces have been changedstring(65) "I'm a "dessert topping" & a <floor wax>! " // same herestring(48) "I'm a "dessert topping" & a <floor wax>! " // escape characters have been addedstring(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
您必须通过选择的清除方法来运行发布的密码，然后才能在密码验证中使用该密码的结果。这是不必要的步骤，会使哈希变得更好。
