清理用户密码 [英] Cleansing User Passwords

问题描述

当PHP开发人员考虑为安全目的散列用户的密码时，我应该如何转义或清理用户提供的密码，然后再将其存入我的数据库中？ ，他们通常倾向于将这些密码想像为其他用户提供的数据。这个问题经常出现在与密码存储相关的PHP问题中;开发人员通常希望使用诸如 escape_string（）（在各种迭代中）， htmlspecialchars（）等函数清理密码。 ， addslashes（）等等，然后将其散列并存储到数据库中。

解决方案

您绝对不应该使用任何其他清理机制来清理您将用PHP的 password_hash（） 为一个数字其中最大的原因是因为对密码进行额外的清理需要不必要的附加代码。

你会争论（并且你会在每篇文章中看到用户数据被接受用于你的系统），我们应该清理所有的用户输入，你会适合我们从我们的用户接受的其他信息。密码是不同的。 哈希密码不能提供任何SQL注入威胁，因为字符串在存储到数据库之前会变成哈希。

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

如果您遵循允许用户使用密码/短语他们希望和你不限制密码，允许任何长度，任意数量的空格和任何特殊字符散列，无论密码中包含什么，都将使密码/密码安全无虞。截至目前为止最常见的散列（默认）， PASSWORD_BCRYPT ，将密码变成包含随机盐的60个字符宽的字符串以及哈希密码信息和成本（创建哈希的算法成本）：

PASSWORD_BCRYPT用于使用CRYPT_BLOWFISH算法创建新的密码哈希。这总是会导致使用$ 2y $crypt格式的散列，该格式始终为60个字符。

空间要求用于存储散列值的函数可能随着向函数添加不同的散列函数而发生变化，所以最好在所存储的散列值的列类型上加大一些，例如 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）我是一个甜点顶部& a<地板蜡>！ //最后的空格缺失
字符串（65）我是甜点顶级&&& lt; floor wax& gt ;!//双引号，&符号和大括号已被更改
字符串（65）我是甜点顶级&& lt; floor wax& gt ;!//同此处
字符串（48）I \'ma \甜点顶尖& a< floor wax> ;!//转义字符已被添加
字符串（34）我是一个甜点顶部& a！//看起来像我们缺少的东西
  

我们将这些发送到 password_hash（）？就像上面的查询一样，它们都被哈希化了。尝试验证密码时出现问题。如果我们采用一种或多种这些方法，我们必须在将它们与 password_verify（） 。以下将失败：
$ b $ pre $ password_verify（$ _ POST ['upassword']，$ hashed_pa​​ssword）; //其中$ hashed_pa​​ssword来自数据库查询


您必须通过清理运行发布的密码在使用密码验证中的结果之前选择的方法。这是一个不必要的步骤，并会使哈希没有更好的。

---

使用小于5.5的PHP版本？您可以使用 password_hash（） 兼容包。

您真的不应该使用 MD5密码哈希值。

How should I escape or cleanse user-provided passwords before I hash them and store them in my database?

When PHP developers consider hashing users' passwords for security purposes, they often tend to think of those passwords like they would any other user-provided data. This subject comes up often in PHP questions related to password storage; the developer often wants to cleanse the password using functions such as escape_string()(in various iterations), htmlspecialchars(), addslashes() and others before hashing it and storing it in the database.

解决方案

You should never escape, trim or use any other cleansing mechanism on passwords you'll be hashing with PHP's password_hash() for a number of reasons, the single largest of which is because doing additional cleansing to the password requires unnecessary additional code.

You will argue (and you see it in every post where user data is accepted for use in your systems) that we should cleanse all user input and you would be right for every other piece of information we're accepting from our users. Passwords are different. Hashed passwords cannot offer any SQL injection threat because the string is turned into hash prior to storing in the database.

The act of hashing a password is the act of making the password safe to store in your database. The hash function doesn't give special meaning to any bytes, so no cleansing of its input is required for security reasons

If you follow the mantras of allowing users to use the passwords / phrases they desire and you don't limit passwords, allowing any length, any number of spaces and any special characters hashing will make the password/passphrase safe no matter what is contained within the password. As of right now the most common hash (the default), PASSWORD_BCRYPT, turns the password into a 60 character wide string containing a random salt along with the hashed password information and a cost (the algorithmic cost of creating the hash):

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.

The space requirements for storing the hash are subject to change as different hashing methods are added to the function, so it is always better to go larger on the column type for the stored hash, such as VARCHAR(255) or TEXT.

You could use a complete SQL query as your password and it would be hashed, making it unexecutable by the SQL engine e.g.,

SELECT * FROM `users`;

Could be hashed to $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

Let's see how different sanitizing methods affect the password -

The password is I'm a "dessert topping" & a <floor wax>! (There are 5 spaces at the end of the password which are not displayed here.)

When we apply the following methods of trimming we get some wildy different results:

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']));

Results:

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

What happens when we send these to password_hash()? They all get hashed, just as the query did above. The problem comes in when you try to verify the password. If we employ one or more of these methods we must re-employ them prior to comparing them with password_verify(). The following would fail:

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

You would have to run the posted password through the cleansing method you chose before using the result of that in password verification. It is an unnecessary set of steps and will make the hash no better.

---

Using a PHP version less than 5.5? You can use the password_hash() compatibility pack.

You really shouldn't use MD5 password hashes.

这篇关于清理用户密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！