Spec-Zone .ru
спецификации, руководства, описания, API
|
MySQL перечисляет учетные записи пользователей в user
таблица mysql
база данных. Каждая учетная запись MySQL может быть присвоена пароль, хотя
user
таблица не хранит версию открытого текста пароля, но значение хэш-функции,
вычисленное от этого.
MySQL использует пароли в двух фазах клиент-серверной передачи:
Когда клиент пытается соединиться с сервером, есть начальный шаг аутентификации, в
котором клиент должен представить пароль, у которого есть значение хэш-функции, соответствующее значение
хэш-функции, сохраненное в user
таблица для учетной записи клиент хочет
использовать.
После того, как клиент соединяется, это может (если у этого есть достаточные
полномочия), набор, или измените хэш пароля для учетных записей, перечисленных в user
таблица. Клиент может сделать это при использовании PASSWORD()
функция, чтобы генерировать хэш пароля, или при
использовании генерирующего пароль оператора (CREATE USER
, GRANT
,
или SET PASSWORD
).
Другими словами сервер проверяет значения хэш-функции во время
аутентификации, когда клиент сначала пытается соединиться. Сервер генерирует значения хэш-функции, если соединенный клиент вызывает PASSWORD()
функция
или использование генерирующий пароль оператор, чтобы установить или изменить пароль.
У методов хеширующего пароля в MySQL есть история, описанная после. Эти изменения иллюстрируются изменениями в
следствии PASSWORD()
функция, которая вычисляет значения хэша пароля и в структуре user
таблица, где
пароли сохранены.
Исходный хеширующий метод, произведенный 16 строк байтов. Такие хеши похожи на это:
mysql> SELECT PASSWORD('mypass');
+--------------------+| PASSWORD('mypass') |+--------------------+| 6f8c114b58f2ce9e |+--------------------+
Сохранить пароли учетной записи, Password
столбец user
таблица была в этой точке 16 байтов длиной.
Представленный пароль MySQL 4.1, хеширующий, который обеспечивает лучшую безопасность и уменьшает риск прерываемых паролей. Было несколько аспектов к этому изменению:
Отличающийся PASSWORD()
функционируйте формат результата
Расширение Password
столбец
Управление методом хеширующего значения по умолчанию
Управление разрешенными хеширующими методами для клиентов, пытающихся соединяться с сервером
Изменения в MySQL 4.1 имели место на двух этапах:
MySQL 4.1.0, используемый предварительная версия 4.1 хеширующих методов. Поскольку этот метод был настолько недолгим, следующее обсуждение не говорит больше об этом.
В MySQL 4.1.1 хеширующий метод был изменен, чтобы произвести более длительное 41-байтовое значение хэш-функции:
mysql> SELECT PASSWORD('mypass');
+-------------------------------------------+| PASSWORD('mypass') |+-------------------------------------------+| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |+-------------------------------------------+
У более длинного формата хэша пароля есть лучшие криптографические свойства, и аутентификация клиента, основанная на длинных хешах, более безопасна чем это основанное на более старых коротких хешах.
Размещать более длительные хэши пароля, Password
столбец в user
таблица была изменена в этой точке, чтобы быть 41 байт, ее текущая
длина.
Расширенный Password
столбец может сохранить хэши пароля и в пред4.1 и
в 4.1 форматах. Формат любого данного значения хэш-функции может быть определен два пути:
Длина: 4.1 и пред4.1 хеша составляют 41 и 16 байтов, соответственно.
Хэши пароля в этих 4.1 форматах всегда начинаются"*
"символ, тогда как пароли
в этих пред4.1 форматах никогда не делают.
Чтобы разрешить явную генерацию пред4.1 хэшей пароля, два дополнительных изменения были произведены:
OLD_PASSWORD()
функция была добавлена, который возвращает
значения хэш-функции в 16-байтовом формате.
В целях совместимости, old_passwords
системная переменная была добавлена, чтобы
включить управлению DBA и приложениями хеширующим методом. Значение по умолчанию old_passwords
значение 0 причин, хеширующих, чтобы
использовать 4.1 метода (41-байтовые значения хэш-функции), но установка old_passwords=1
причины, хеширующие, чтобы использовать
пред4.1 метода. В этом случае, PASSWORD()
производит 16-байтовые значения и эквивалентен
OLD_PASSWORD()
Чтобы разрешить DBA управляют по тому, как клиентам разрешают соединиться, secure_auth
системная переменная была добавлена. Запуск сервера с
этой переменной отключенные или включенные разрешения или запрещает, что клиенты соединяют
использование более старых пред4.1 методов хеширующего пароля. Перед MySQL 5.6.5, secure_auth
отключается по умолчанию. С 5.6.5, secure_auth
позволяется по умолчанию продвинуть более безопасную
конфигурацию значения по умолчанию. (DBA могут отключить это по своему усмотрению, но это не
рекомендуется.)
Кроме того, mysql
клиент поддерживает a --secure-auth
опция, которая походит secure_auth
, но от стороны клиента. Это может использоваться,
чтобы предотвратить соединения с менее безопасными учетными записями, которые используют пред4.1
хеширующие пароля. Эта опция отключается по умолчанию перед MySQL 5.6.7, включенным после того.
Расширение Password
столбец в MySQL 4.1 от 16 байтов до 41 байта влияет на
установку или операции обновления следующим образом:
Если Вы выполняете новую установку MySQL, Password
столбец делается 41 байт длиной автоматически.
Обновления от MySQL 4.1 или позже к текущим версиям MySQL не должны дать начало
никаким проблемам в отношении Password
столбец, потому что обе версии
используют ту же самую длину столбца и метод хеширующего пароля.
Для обновлений от пред4.1 выпусков до 4.1 или позже, следует обновить системные таблицы после обновления. (См. Раздел 4.4.7, "mysql_upgrade — Таблицы MySQL Check и Upgrade".)
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 root
Client does not support authentication protocol requestedby server; consider upgrading MySQL client
Это явление также происходит для попыток использовать более старый PHP mysql
расширение после обновления до MySQL 4.1 или более новый. (См. Раздел
21.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 клиента могут соединиться, но потому что они знают только о пред4.1 хеширующих методах, они могут аутентифицировать только учетные записи использования, у которых есть короткие хеши.
4.1 и позже клиенты могут аутентифицировать учетные записи использования, у которых есть короткие или длинные хеши.
Даже для учетных записей короткого хеша, процесс аутентификации фактически немного более безопасен для 4.1 и позже клиенты чем для клиентов старшего возраста. С точки зрения безопасности градиент от меньше всего до самого безопасного:
Пред4.1 клиента, аутентифицирующие с коротким хэшем пароля
4.1 или более поздний клиент, аутентифицирующий с коротким хэшем пароля
4.1 или более поздний клиент, аутентифицирующий с долгим хэшем пароля
На путь, которым сервер генерирует хэши пароля для соединенных клиентов, влияет width Password
столбец и old_passwords
системная переменная. 4.1 или более поздний сервер генерируют длинные хеши, только если определенные условия
соблюдаются: Password
столбец должен быть достаточно широким, чтобы содержать
длинные значения и old_passwords
не должен быть установлен в 1.
Те условия применяются следующим образом:
Password
столбец должен быть достаточно широким, чтобы
содержать длинные хеши (41 байт). Если столбец не был обновлен и все еще имеет пред4.1 width 16 байтов,
сервер замечает, что длинные хеши не могут вписаться в это и генерируют только короткие хеши, когда
клиент выполняет изменяющие пароль операции, используя PASSWORD()
функционируйте или генерирующий пароль оператор. Это -
поведение, которое происходит, если Вы обновили от версии MySQL, более старого чем 4.1 к 4.1 или позже,
но еще не выполнили mysql_upgrade программу, чтобы расшириться Password
столбец.
Если Password
столбец широк, он может сохранить или
короткие или долгие хэши пароля. В этом случае, PASSWORD()
функционируйте и генерирующие пароль операторы генерируют
длинные хеши, если сервер не был запущен с old_passwords
системный набор переменной к 1, чтобы вынудить сервер
генерировать короткие хэши пароля вместо этого.
Цель old_passwords
системная переменная должна разрешить обратную совместимость с
пред4.1 клиентами при обстоятельствах, где сервер иначе генерировал бы долгие хэши пароля. Опция не влияет на
аутентификацию (4.1, и позже клиенты могут все еще использовать учетные записи, у которых есть долгие хэши
пароля), но это действительно предотвращает создание долгого хэша пароля в user
таблица как результат изменяющей пароль работы. Были это разрешало происходить, учетная запись больше не могла
использоваться пред4.1 клиентами. С old_passwords
отключенный, следующий нежелательный сценарий возможен:
Старые пред4.1 клиента соединяются с учетной записью, у которой есть короткий хэш пароля.
Клиент изменяет его собственный пароль. С old_passwords
отключенный, это приводит к учетной записи, имеющей долгий
хэш пароля.
В следующий раз, когда старый клиент пытается соединиться с учетной записью, она не может, потому что у учетной записи есть долгий хэш пароля, который требует 4.1 хеширующих методов во время аутентификации. (Как только у учетной записи есть долгий хэш пароля в пользовательской таблице, только 4.1, и позже клиенты могут аутентифицировать для этого, потому что пред4.1 клиента не понимают длинные хеши.)
Этот сценарий иллюстрирует, что, если следует поддерживать пред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
столбец в
пользовательской таблице:
Только короткие хеши могут быть сохранены в Password
столбец.
Сервер использует только короткие хеши во время аутентификации клиента.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD()
функционируйте или генерирующие пароль операторы используют короткие хеши исключительно. Любое изменение
к паролю учетной записи приводит к той учетной записи, имеющей короткий хэш пароля.
Значение old_passwords
не важно потому что с коротким Password
столбец, сервер генерирует только короткие хэши пароля так или иначе.
Этот сценарий происходит, когда пред4.1 установки MySQL были обновлены до 4.1 или позже но mysql_upgrade не был выполнен, чтобы обновить системные таблицы
в mysql
база данных. (Это не рекомендуемая конфигурация, потому что она не
разрешает использование более безопасных 4.1 хеширующих паролей.)
Сценарий 2: Долго Password
столбец;
сервер, запущенный с old_passwords=1
:
Короткие или длинные хеши могут быть сохранены в Password
столбец.
4.1 и позже клиенты могут аутентифицировать для учетных записей, у которых есть короткие или длинные хеши.
Пред4.1 клиента могут аутентифицировать только для учетных записей, у которых есть короткие хеши.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD()
функционируйте или генерирующие пароль операторы используют короткие хеши исключительно. Любое изменение
к паролю учетной записи приводит к той учетной записи, имеющей короткий хэш пароля.
В этом сценарии у недавно создаваемых учетных записей есть короткие хэши пароля потому что 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
:
Короткие или длинные хеши могут быть сохранены в Password
столбец.
4.1 и позже клиенты могут аутентифицировать учетные записи использования, у которых есть короткие или длинные хеши.
Пред4.1 клиента могут аутентифицировать только учетные записи использования, у которых есть короткие хеши.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD()
функционируйте или генерирующие пароль операторы используют длинные хеши исключительно. Изменение к
паролю учетной записи приводит к той учетной записи, имеющей долгий хэш пароля.
Как обозначено ранее, опасность в этом сценарии состоит в том, что это возможно для учетных записей, у которых
есть короткий хэш пароля, чтобы стать недоступными пред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()
.
Лучший способ избежать проблем совместимости, связанных с короткими хэшами пароля, не состоит в том, чтобы использовать их:
Обновите все клиентские программы до MySQL 4.1 или позже.
Выполните сервер с old_passwords=0
.
Сбросьте пароль для любой учетной записи с коротким хэшем пароля, чтобы использовать долгий хэш пароля.
Для дополнительной безопасности, выполненной сервер с secure_auth=1
.