userMySQL在数据库表中 列出用户帐户mysql。每个 MySQL 帐户都可以分配一个密码，尽管该user 表不存储密码的明文版本，而是从中计算出的哈希值。

MySQL 在客户端/服务器通信的两个阶段使用密码：

换句话说，当客户端首次尝试连接时，服务器会在身份验证期间检查哈希值。如果连接的客户端调用该 函数或使用密码生成语句来设置或更改密码， 则服务器会生成哈希值。PASSWORD()

MySQL 中的密码散列方法具有以下描述的历史。这些变化通过PASSWORD() 计算密码哈希值的函数的结果变化以及user存储密码的表的结构的变化来说明。

原始的（Pre-4.1）哈希方法

原始的散列方法产生一个 16 字节的字符串。这样的哈希看起来像这样：

mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e   |
+--------------------+

为了存储帐户密码，表的Password 列user此时为 16 字节长。

4.1 散列法

MySQL 4.1 引入了密码哈希，提供了更好的安全性并降低了密码被拦截的风险。这种变化有几个方面：

MySQL 4.1 的变化分两个阶段进行：

与哈希方法相关的兼容性问题

MySQL 4.1中的列从 16 字节加宽Password到 41 字节对安装或升级操作的影响如下：

4.1 哈希方法只有 MySQL 4.1（及更高版本）服务器和客户端才能理解，这可能会导致一些兼容性问题。4.1 或更高版本的客户端可以连接到 4.1 之前的服务器，因为客户端理解 4.1 之前和 4.1 之前的密码哈希方法。但是，尝试连接到 4.1 或更高版本服务器的 pre-4.1 客户端可能会遇到困难。例如，4.0 mysql客户端可能会失败并显示以下错误消息：

$> mysql -h localhost -u root
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

下面的讨论描述了 4.1 之前和 4.1 之前的哈希方法之间的区别，以及如果您升级服务器但需要保持与 4.1 之前的客户端的向后兼容性，您应该做什么。（但是，不建议允许旧客户端连接，如果可能应避免。）此信息对于将 MySQL 数据库从 4.1 之前的版本迁移到 4.1 或更高版本的 PHP 程序员特别重要。

短密码哈希和长密码哈希之间的差异与服务器在身份验证期间如何使用密码以及服务器如何为执行密码更改操作的已连接客户端生成密码哈希有关。

服务器在身份验证期间使用密码哈希的方式受 Password列宽的影响：

即使对于短哈希帐户，身份验证过程对于 4.1 及更高版本的客户端实际上比旧客户端更安全。在安全性方面，从最不安全到最安全的梯度是：

服务器为连接的客户端生成密码哈希的方式受 Password列宽和 old_passwords系统变量的影响。4.1 或更高版本的服务器仅在满足某些条件时才生成长散列：Password列必须足够宽以容纳长值并且 old_passwords不得设置为 1。

这些条件适用如下：

系统变量的目的 old_passwords是在服务器会生成长密码哈希值的情况下允许与 4.1 之前的客户端向后兼容。该选项不影响身份验证（4.1 及更高版本的客户端仍然可以使用具有长密码哈希的帐户），但它确实可以防止user由于密码更改操作而在表中创建长密码哈希。如果允许发生这种情况，4.1 之前的客户将无法再使用该帐户。禁用后， old_passwords可能会出现以下不良情况：

此场景说明，如果您必须支持较旧的 4.1 之前的客户端，则在未old_passwords设置为 1 的情况下运行 4.1 或更高版本的服务器会出现问题。通过使用 运行服务器 old_passwords=1，密码更改操作不会生成长密码哈希，因此不会导致老客户无法访问帐户。（这些客户不会无意中通过更改密码并以长密码散列结束而将自己锁在门外。）

的缺点old_passwords=1 是任何创建或更改的密码都使用短散列，即使对于 4.1 或更高版本的客户端也是如此。因此，您失去了长密码哈希提供的额外安全性。要创建具有长哈希的帐户（例如，供 4.1 客户端使用）或更改现有帐户以使用长密码哈希，管理员可以将会话值 old_passwords设置为 0，同时将全局值设置为1:

mysql> SET @@SESSION.old_passwords = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@SESSION.old_passwords, @@GLOBAL.old_passwords;
+-------------------------+------------------------+
| @@SESSION.old_passwords | @@GLOBAL.old_passwords |
+-------------------------+------------------------+
|                       0 |                      1 |
+-------------------------+------------------------+
1 row in set (0.00 sec)

mysql> CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'newpass';
Query OK, 0 rows affected (0.03 sec)

mysql> SET PASSWORD FOR 'existinguser'@'localhost' = PASSWORD('existingpass');
Query OK, 0 rows affected (0.00 sec)

以下场景在 MySQL 4.1 或更高版本中是可能的。这些因素是该Password列是短列还是长列，如果是长列，则服务器是在 old_passwords启用还是禁用状态下启动的。

场景一：用户表中的短 Password列：

当 4.1 之前的 MySQL 安装已升级到 4.1 或更高版本但 尚未运行 mysql_upgrademysql以升级数据库中的系统表时，会发生这种情况。（这不是推荐的配置，因为它不允许使用更安全的 4.1 密码散列。）

场景二：长 Password列；服务器开始于 old_passwords=1：

在这种情况下，新创建的帐户具有短密码哈希值，因为old_passwords=1 可以防止生成长哈希值。此外，如果您在设置 old_passwords为 1 之前创建了一个具有长散列的帐户，则更改帐户的密码会 old_passwords=1导致为该帐户提供一个短密码，从而使其失去较长散列的安全优势。

要创建具有长密码哈希的新帐户，或将任何现有帐户的密码更改为使用长哈希，首先将会话值 old_passwords设置为 0，同时将全局值设置为 1，如前所述。

在这种情况下，服务器有一个最新的 Password列，但运行时使用默认密码散列方法设置以生成 pre-4.1 散列值。这不是推荐的配置，但在 4.1 之前的客户端和密码升级到 4.1 或更高版本的过渡期间可能会有用。完成后，最好使用 old_passwords=0和 运行服务器secure_auth=1。

场景三：长 Password列；服务器开始于 old_passwords=0：

如前所述，这种情况下的一个危险是，4.1 之前的客户端可能无法访问具有短密码哈希的帐户。使用 PASSWORD()函数或密码生成语句更改此类帐户的密码会导致帐户获得长密码哈希。从那时起，没有 pre-4.1 客户端可以使用该帐户连接到服务器。客户端必须升级到 4.1 或更高版本。

如果这是一个问题，您可以通过特殊方式更改密码。例如，通常您使用SET PASSWORD如下方式更改帐户密码：

SET PASSWORD FOR 'some_user'@'some_host' = PASSWORD('password');

要更改密码但创建一个短散列，请改用该 OLD_PASSWORD()函数：

SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('password');

OLD_PASSWORD()对于您明确想要生成短散列的情况很有用。

上述每种情况的缺点可归纳如下：

在场景 1 中，您无法利用提供更安全身份验证的更长哈希值。

在方案 2 中，old_passwords=1 防止具有短哈希值的帐户变得不可访问，但密码更改操作会导致具有长哈希值的帐户恢复为短哈希值，除非您先注意将会话值更改old_passwords 为 0。

在场景 3 中，如果您在未明确使用OLD_PASSWORD().

避免与短密码哈希相关的兼容性问题的最佳方法是不使用它们：