назад вверх вперёд содержание НПО Криста

Подразделы


Про пароли

Откуда они берутся

На первый взгляд вроде бы пароль вводит пользователь при подключении. Ну и администратор при регистрации пользователя на сервере. Казалось бы -- чего тут думать? Однако кое-какие хитрости здесь имеются.

Всё началось несколько месяцев назад, когда ряд моих коллег обнаружил (не без ужаса), что иногда к серверу можно подключиться под SYSDBA не вводя пароля. Или с паролем, гораздо более длинным, нежели он реально установлен. В ходе дальнейших разбирательств выяснилось, что даже убивание переменных ISC_USER и ISC_PASSWORD проблему иногда не устраняет -- вводишь SYSDBA, жмёшь Enter, и оказываешься в базе под полными правами.

В конце концов выяснилось, что коварные переменные были установлены ... в сервере. И этого оказалось достаточно. В результате методичного перебора комбинаций было выяснено следующее (сервер был тогда 4.2/NT).

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

Наименее актуальна данная проблема для классической архитектуры под *nix. Ведь inetd обычно запускается из стартовых скриптов системы, в то время как ISC_* устанавливаются в пользовательском окружении, где-нибудь в profile. За весь свой опыт не помню, чтобы эти вещи у меня пересеклись.

Абсолютно безопасна с точки зрения данной проблемы, на мой взгляд, платформа NetWare. Там переменных окружения вообще нет. По крайней мере в те времена, когда я имел дело с 3.11 и 3.12, ничего такого не было. Хотя конечно, NetWare неудобна для сервера баз данных по другим причинам.

С другой стороны, наиболее вероятна подобная ситуация под NT, с её возможностью глобальной настройки переменных, включаемых во все окружения. 10 раз подумайте, прежде чем добавлять туда что-либо, особенно пароль! И даже если это не связано с InterBase . Собственно под NT данная опасность и была обнаружена.

Аналогичным образом потенциально опасны настройки, сделанные в autoexec.bat под Win9x. Кроме того, об окружении никогда нельзя забывать, когда запускаешь сервер ``руками'', на какой бы платформе это ни происходило.

Как они шифруются

Ещё один вопрос, породивший недавно целую волну проблем в Linux и FreeBSD. Как известно, InterBase изначально создавался под Unix, и лишь затем портирован на другие платформы. В связи с чем авторы использовали для шифрования паролей самое простое решение -- стандартную для Unix функцию crypt(). Ту же самую, что и используется самим Unix'ом для тех же (в том числе) целей. Соответственно во многих системах пароли можно (было) переносить из /etc/passwd или /etc/shadow в isd4.gdb (поле users.passwd). И обратно. При этом всё работало.

Здесь надо заметить, что упомянутая технология на самом деле предусматривает шифрование лишь первых 64 бит пароля, то есть 8 символов. С учётом выкидывания пробелов. Остальные символы могут быть любыми. Благодаря этому, например, вместо ``masterkey'' можно написать ``masterkeyxyz'', и даже ``masterke''.

Всё это нормально работало до тех пор, пока на всех платформах был crypt(), использовавший для шифрования стандартный алгоритм DES. Но предположение об этом вообще-то, уже не уже само по себе сомнительно, потому что полной гарантии относительно того, что алгоритм и формат шифрования не изменится, не было. Именно такое изменение впоследствии и произошло.

Но сначала почва для проблем была дополнительно подготовлена при портировании InterBase на платформы, не имеющие crypt(). Естественно, в код, специфичный для этих платформ была включена функция crypt(), позаимствованная из Unix. Однако в InterBase для предыдущих платформ это заимствование внесено не было. Таким образом возник ещё один повод, чтобы с одной стороны поменялось, а с другой -- нет.

И наконец, настал тот день, когда алгоритм шифрования под Unix начал меняться. Вместо старого, по нынешним временам малоразрядного и обросшего несметным количеством кряков DES функцию crypt() научили MD5. Если не вдаваться в подробности, то MD5 шифрует по другому алгоритму (строго говоря -- это алгоритм хеширования, обратную операцию, то есть расшифровку, вообще не поддерживает) и работает с паролями большей длины. И естественно, если на одном конце пароль зашифрован по одной технологии, а на другом конце соединения установлена другая, то сравнение потерпит неудачу и пользователь до работы допущен не будет.

Замена произошла, насколько мне известно, при переходе к glibc 2.1, в частности в системах Linux и FreeBSD. Более того, новая версия пакета системных библиотек содержала по умолчанию поддержку нового MD5, а старый DES поставлялся в виде отдельной библиотеки descrypt, которую следовало доустановить при острой необходимости в обратной совместимости. Многие пользователи и администраторы с непривычки этот момент упустили.

В результате возникла ситуация, в типичном случае примерно следующая: клиенты под Windows используют DES (единственное, что зашито в них авторами InterBase), а сервера под *nix -- MD5. Подключиться невозможно. Более того, база isc4.gdb, поставляемая с InterBase, изначально содержит SYSDBA/masterkey, причём пароль зашифрован именно DES. В результате после такой установки даже первые администраторские подключения внутри одной системы осуществить невозможно.

К сожалению, я не могу сказать, как дальше будет развиваться ситуация с платформами и технологиями шифрования. Пока же наиболее разумный и правильный подход -- привести всё к единому, давно принятому в InterBase стандарту, DES. То есть при установке сервера под *nix необходимо удостовериться, что необходимые библиотеки установлены. К счастью, начиная с glibc2.2 похоже, что обе технологии шифрования будут поставляться вместе и ничего доустанавливать не потребуется.


назад вверх вперёд содержание НПО Криста