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 клиента могут перестать работать со следующим сообщением об ошибке:

shell> mysql -h localhost -u rootClient does not support authentication protocol requestedby server; consider upgrading MySQL client

Это явление также происходит для попыток использовать более старый PHP mysql расширение после обновления до MySQL 4.1 или более новый. (См. Раздел 22.9.12, "Типичные проблемы с MySQL и PHP".)

Следующее обсуждение описывает различия между пред4.1 и 4.1 хеширующими методами, и что следует сделать, если Вы обновляете свой сервер, но должны поддержать обратную совместимость с пред4.1 клиентами. (Однако, разрешение соединений старыми клиентами не рекомендуется и должно избежаться если возможный.) Дополнительная информация может быть сочтена в Разделе C.5.2.4,"Client does not support authentication protocol". Эта информация имеет особое значение для баз данных MySQL перехода PHP программистов от версий, более старых чем 4.1 к 4.1 или выше.

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

На путь, которым сервер использует хэши пароля во время аутентификации, влияет width Password столбец:

Даже для учетных записей короткого хеша, процесс аутентификации фактически немного более безопасен для 4.1 и позже клиенты чем для клиентов старшего возраста. С точки зрения безопасности градиент от меньше всего до самого безопасного:

На путь, которым сервер генерирует хэши пароля для соединенных клиентов, влияет width 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 столбец в пользовательской таблице:

Этот сценарий происходит, когда пред4.1 установки MySQL были обновлены до 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('mypass');

Чтобы изменить пароль, но создать короткий хеш, используйте OLD_PASSWORD() функция вместо этого:

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

OLD_PASSWORD() полезно для ситуаций, в которых Вы явно хотите генерировать короткий хеш.

Недостатки для каждого из предыдущих сценариев могут быть получены в итоге следующим образом:

В сценарии 1 невозможно использовать в своих интересах более длинные хеши, которые обеспечивают более безопасную аутентификацию.

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

В сценарии 3 учетные записи с короткими хешами становятся недоступными пред4.1 клиентам, если Вы изменяете их пароли без явного использования OLD_PASSWORD().

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