php清理在线用户,php – 清理用户密码

你不应该逃避，修剪或使用任何其他清理机制的密码，你将使用PHP的

password_hash()散列有多个原因，其中最大的一个是因为做额外的清理密码需要不必要的附加代码。

你会争论(在你的系统中接受用户数据的每个帖子中都会看到)，我们应该清除所有的用户输入，你将适合我们接受来自用户的其他信息。密码不同。哈希的密码不能提供任何SQL注入威胁，因为字符串在存储在数据库之前变成哈希。

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

如果你遵循允许用户使用他们渴望的passwords / phrases和你don’t limit passwords，允许任何长度，任何数量的空格和任何特殊字符哈希将使密码/密码安全，无论密码中包含什么的咒语。到目前为止，最常见的哈希值(默认值)PASSWORD_BCRYPT将密码变为包含随机盐的60字符宽字符串以及哈希密码信息和开销(创建哈希的算法成本)：

PASSWORD_BCRYPT is used to create new password hashes using the CRYPT_BLOWFISH algorithm. This will always result in a hash using the “$2y$” crypt format, which is always 60 characters wide.

存储哈希的空间要求会随着不同的哈希方法被添加到函数而改变，因此对于存储的哈希的列类型(例如VARCHAR(255)或TEXT)总是更好。

您可以使用完整的SQL查询作为您的密码，它将被哈希处理，使其不能由SQL引擎执行，例如，

SELECT * FROM `users`;

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

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

密码是我是一个“甜点顶”& 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 !" // spaces at the end are missing

string(65) "I'm a "dessert topping" & a <floor wax>! " // double quotes, ampersand and braces have been changed

string(65) "I'm a "dessert topping" & a <floor wax>! " // same here

string(48) "I\'m a \"dessert topping\" & a ! " // 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

您必须通过您选择的清理方法运行发布的密码，然后再使用密码验证的结果。这是一个不必要的步骤，将使散列不更好。

使用PHP版本低于5.5？您可以使用password_hash()compatibility pack。