MySQL хранит учетные записи пользователей в таблице user базы данных mysql. Каждой учетной записи MySQL можно назначить пароль, хотя таблица user не хранит явный вид пароля, а хранит вычисленный из него хэш.

MySQL использует пароли в двух фазах взаимодействия клиент-сервер:

Другими словами, сервер проверяет хэши во время аутентификации, когда клиент впервые пытается подключиться. Сервер генерирует хэши, если подключенный клиент вызывает функцию PASSWORD() или использует оператор генерации пароля для установки или изменения пароля.

Методы хэширования паролей в MySQL имеют описанную ниже историю. Эти изменения отражены в результатах функции PASSWORD(), которая вычисляет хэши паролей, и в структуре таблицы user, где хранятся пароли.

Исходный (до 4.1) метод хэширования

Исходный метод хэширования создавал строку длиной 16 байт. Такие хэши выглядят так:

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

Для хранения паролей учетных записей столбец Password таблицы user на этом этапе имел длину 16 байт.

Метод хэширования 4.1

MySQL 4.1 ввёл метод хэширования паролей, обеспечивающий лучшую безопасность и снижающий риск перехвата паролей. Эта смена включала в себя несколько аспектов:

Изменения в MySQL 4.1 произошли в два этапа:

Проблемы совместимости, связанные с методами хэширования

Расширение столбца Password в MySQL 4.1 с 16 байт до 41 байта влияет на операции установки или обновления следующим образом:

Метод хэширования 4.1 понимается только серверами и клиентами MySQL 4.1 (и более поздними версиями), что может привести к некоторым проблемам совместимости. Клиент 4.1 или более поздней версии может подключаться к серверу до 4.1, потому что клиент понимает оба метода хэширования паролей до 4.1 и 4.1. Однако клиент до 4.1, пытающийся подключиться к серверу 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. (Однако разрешение подключений старыми клиентами не рекомендуется и следует избегать, если это возможно.) Эта информация особенно важна для программистов PHP, мигрирующих базы данных MySQL из версий, более ранних, чем 4.1, в 4.1 или более поздние.

Различия между короткими и длинными хэшами паролей актуальны как для того, как сервер использует пароли во время аутентификации, так и для того, как он генерирует хэши паролей для подключённых клиентов, которые выполняют операции изменения паролей.

Способ, которым сервер использует хэши паролей во время аутентификации, зависит от ширины столбца 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, проблематично запустить сервер 4.1 или более поздней версии без установленного значения old_passwords в 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.

Сценарий 1: Короткая колонка Password в таблице пользователей:

Этот сценарий возникает, когда установочная версия MySQL до 4.1 была обновлена до 4.1 или более поздней, но программа mysql_upgrade не была запущена для обновления системных таблиц в базе данных mysql. (Это не рекомендуемая конфигурация, поскольку она не позволяет использовать более безопасное хеширование паролей версии 4.1).

Сценарий 2: Длинная колонка Password; сервер запущен с включённой old_passwords=1:

В этом сценарии новые учётные записи имеют короткие хеши паролей, потому что old_passwords=1 предотвращает генерацию длинных хешей. Кроме того, если вы создадите учётную запись с длинным хешем перед установкой old_passwords в 1, изменение пароля учётной записи при включенной old_passwords=1 приведёт к тому, что учётная запись получит короткий хеш, потеряв преимущества более длинного хеша.

Чтобы создать новую учётную запись с длинным хешем пароля или изменить пароль любой существующей учётной записи на использование длинного хеша, сначала установите значение сессии old_passwords в 0, оставив глобальное значение в 1, как описано ранее.

В этом сценарии сервер имеет обновлённую колонку Password, но работает с параметрами хеширования паролей по умолчанию, настроенными на генерацию значений хешей до версии 4.1. Это не рекомендуемая конфигурация, но может быть полезна в переходный период, когда клиенты и пароли до версии 4.1 обновляются до 4.1 или более поздних версий. После этого предпочтительно запустить сервер с включёнными параметрами old_passwords=0 и secure_auth=1.

Сценарий 3: Длинная колонка Password; сервер запущен с включённой old_passwords=0:

Как уже упоминалось, опасность в этом сценарии заключается в том, что учётные записи, которые имеют короткий хеш пароля, могут стать недоступными для клиентов до версии 4.1. Изменение пароля такой учётной записи с помощью функции PASSWORD() или оператора генерации паролей приводит к тому, что учётная запись получает длинный хеш пароля. С этого момента ни один клиент до версии 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, учетные записи с короткими хешами становятся недоступными для клиентов версии до 4.1, если вы изменяете их пароли без явного использования OLD_PASSWORD().

Лучший способ избежать проблем совместимости, связанных с короткими хешами паролей, — не использовать их: