Краткое введение
Парольная защита является наиболее распространенным способом аутентификации пользователей в современных информационных системах (ИС). Пользователь вводит пароль, сервер сравнивает значение, введенное пользователем с тем, что хранится у него в памяти и в зависимости от результата сравнения разрешает или отвергает подключение пользователя.
С хранением и передачей пароля связаны основные проблемы:
- Если передавать пароль в открытом виде, то его можно узнать, слушая пакеты по сети.
- Хранить пароль в сервере в открытом виде тоже небезопасно, т.к. его можно подсмотреть.
Таким образом, пароль приходится шифровать.
Вопрос об алгоритме шифрования паролей в СУБД Oracle практически не освещен в русскоязычной литературе и Интернет, хотя имеет важное значение для безопасного хранения данных в базе данных.
Система шифрования паролей является достаточно консервативным элементом СУБД, ибо ее малейшее изменение влияет на возможность/невозможность подключения клиентов к базе данных. Таким образом, частое изменение этой подсистемы СУБД нежелательно. Видимо, этот фактор сказался на том, что подсистема шифрования паролей была неизменной много лет, по моим оценкам - около 15. Изменение системы шифрования повлекло бы за собой ряд сообщений ORA-xxxxx, сообщающих об ошибках в системе шифрования и в технической документации были бы упомянуты причины и способы их решения. Судя по отсутствию этих проблем в технической документации и Интернет, можно сделать вывод, что в СУБД Oracle подсистема шифрования паролей была неизменной достаточно длительное время, где-то последние 15 лет.
До определенного момента о подсистеме шифрования паролей в СУБД Oracle вообще не было ничего неизвестно, несмотря на то, что система шифрования СУБД Oracle не может быть секретной, поскольку эта СУБД эксплуатируется во всем мире, а не только в защищенных ВЦ США.
Мои экспериментальные исследования этого вопроса привели к нескольким экспериментально установленным фактам.
Первым фактом стало то, что в СУБД Oracle не различаются строчные и заглавные символы. Затем эксперименты с прослушиванием сетевых пакетов показали, что клиентский пароль не передается на сервер в открытом виде. Следовательно, обработка клиентского пароля осуществляется на клиенте, и для защиты пароля используется какой-то алгоритм шифрования. И, скорее всего, этот алгоритм - DES, поскольку другого общедоступного сертифицированного алгоритма, существовавшего на протяжении последних 15 лет в США нет.
Постепенно стало очевидно, что в СУБД Oracle на все инсталляции используется один и тот же ключ, потому что шифрование осуществляется на клиенте, но при этом, клиент может подключаться ко всем базам данных, независимо от аппаратной платформы, битности, версий ОС и версий Oracle. Иными словами, проинсталлировав клиента у себя в ПК под Windows, я могу подключаться к любой базе данных Oracle. Значит, значение ключа не является функцией, зависящей от версии СУБД, типа инсталляции (клиент или сервер), версии ОС. Очевидно, что сам собой напрашивается вывод о том, что ключ является константой, единой на все инсталляции СУБД, а значение этой константы «зашито» в каждом дистрибутиве, и даже конкретно в каждом исполняемом файле sqlplus. Таким образом, взяв один дистрибутив можно было узнать ключ, а, узнав ключ, можно расшифровать и получить в открытом виде пароль!
А вот это уже в голове не укладывалось: подобная криптосистема - это ошибка с точки зрения криптографической защиты, или компания сознательно пожертвовала безопасностью в угоду удобствам эксплуатации? Однако детали этой конструкции были покрыты мраком.
Погружаться в декомпилирование кода СУБД не было возможности, поэтому данная проблема так и не нашла своего решения.
Последним штрихом для создания полноценной картины явилось опубликование 18 октября 2005 г. исследования «An Assessment of the Oracle Password Hashing Algorithm» авторов Joshua Wright и Carlos Cid, в котором описан алгоритм шифрования паролей в СУБД Oracle.
