Шифрование паролей в СУБД Oracle

2007 г.

Шифрование паролей в СУБД Oracle

к.ф.-м.н. Пудовченко Ю.Е.

Краткое введение

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

С хранением и передачей пароля связаны основные проблемы:

Если передавать пароль в открытом виде, то его можно узнать, слушая пакеты по сети.
Хранить пароль в сервере в открытом виде тоже небезопасно, т.к. его можно подсмотреть.

Таким образом, пароль приходится шифровать.

Вопрос об алгоритме шифрования паролей в СУБД 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.

История парольной защиты

Одними из первых, кто понял, что в ИС не обязательно хранить сами пароли, были Роджер Нидхам и Майк Гай [2]. Достаточно, чтобы ИС могла отличать достоверные пароли от недостоверных. В современных ИС для этой цели хранится хеш¹ пароля, т.е. результат применения к паролю хеш-функции.

Исторически были выработаны следующие принципы парольной защиты [3,4,5]:

Выбор сложных паролей. Главная атака на пароль состоит в переборе всех возможных паролей указанной длины, вычисление его хеша и сравнение с образцом. Вычисления могут быть произведены противником заранее, на быстродействующей ЭВМ, а затем сохранены в базе данных в виде индексированного дерева, что позволит при необходимости быстро проверить наличие искомого пароля. А поскольку пользователи зачастую выбирают легко запоминающиеся пароли, то тем самым они невольно способствуют злоумышленнику, сокращая пространство возможных значений. Для удобства вскрытия злоумышленник может составить словарь наиболее употребительных паролей. Итак, самое слабое место парольной защиты это низкая энтропия обычных паролей.
Использование случайного числа-привязки (соль). Хеш-функция является детерминированной. Будучи примененной к одним и тем же исходным данным, она в результате выдает одно и то же значение. Следовательно, два разных пользователя, выбрав один и тот же пароль, получат в результате одно и то же хеш-значение. Таким образом, пользователь, не обладая глубокими знаниями в области вскрытия шифров, а, зная только свой собственный пароль, сможет просмотреть все хеш-значения и определить других пользователей с таким же, как у него паролем. Чтобы предотвратить подобную уязвимость, каждый пароль имеет ассоциированное с ним случайное число, которое используется совместно с паролем для генерации хеша пароля. Обычно это случайное число побитово складывается с паролем, в результате чего на вход хеш-функции подаются различные данные, даже если пользователи вводят один и тот же пароль. Случайное число достаточной длины позволяет также затруднить атаку на пароли за счет того, что не позволяет противнику заранее вычислить все возможные пароли заданной длины и их хеши и реализовать атаку по словарю.
Медленный однонаправленный алгоритм. Медленный однонаправленный алгоритм означает, что хеш-функция не должна вычисляться быстро. Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Поэтому медленный однонаправленный алгоритм нужен, чтобы замедлить работу хакеров. Он не сильно затруднит одноразовое вычисление пароля (например, при подключении к БД), но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение здесь - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.
Устройство системы не должно быть секретом. Секретным элементом должен быть только сменный элемент системы, например, ключ шифрования.
По умолчанию доступ к системе не предоставляется.
Система защиты должна быть дружественной. Даже очень надежная система защиты, которая в значительной мере мешает ему выполнять свои функции, в конце концов, будет отвергнута.

Алгоритм

Как описано в документации, в СУБД Oracle для создания паролей может использоваться следующий набор символов:

цифры '0123456789',
буквы 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
символы !"#$%&()`*+,-/:;<=>?_.

Поскольку все символы преобразуются к верхнему регистру, то мощность алфавита паролей равна 10+26+21=57 символов. В результате допустимых паролей может быть (все пароли длиной 1 символ, плюс все пароли длиной два символа и т.д. до 30 символов). Однако, во многих случая этот набор немного меньше, потому что некоторые символы из п.3 неудобно использовать, например, в скриптах shell.

Эксперименты показали, что в качестве пароля могут выступать вообще любые символы:

SQL> create user yu identified by "Пудовченко";
User created.

SQL> create user yu2 identified by "";
User created.

Ключевым моментом здесь является то, что синтаксис сервера Oracle позволяет конструкции с двойными кавычками, между которыми может находиться любой символ.

В базе данных пароли пользователей хранятся в виде 8-байтовых хешей в таблице SYS.USER$.

В [1] этот алгоритм описан так:

Конкатенировать логин и пароль пользователя (обозначим эту операцию ||).
Преобразовать полученную строку к верхнему регистру (UPPER(Логин||Пароль)).
Если в ОС используется однобайтовая кодировка, то преобразовать каждый символ в двухбайтовый, заполнив старший байт нулями (0x00).
Зашифровать получившуюся строку (дополняя ее нулями до длины блока), используя алгоритм DES в режиме CBC с фиксированным ключом, значение которого есть 0x0123456789ABCDEF.
Зашифровать получившуюся строку еще раз с помощью DES-CBC, но используя последний блок предыдущего шага как ключ шифрования.

Графически это выглядит следующим образом:

Обозначим шифрование строки Х на ключе K как DES(X,K). Тогда, в аналитической форме уравнение шифрования выглядит так:

H = DES(UPPER(Логин||Пароль), DES(UPPER(Логин||Пароль), K)) (1)

Если обозначить UPPER(Логин||Пароль) =Х, то уравнение станет совсем простым:

H=DES(X,DES(X,K)) (2)

Обратную операцию (расшифрование H на ключе K) обозначим так: X=DES^-1(H,K).

Алгоритм шифрования DES определен для 56-битового ключа, но не во всех версиях СУБД Oracle выдерживается значение 56 бит. В силу ограничений экспортного законодательства США в 80-90 гг., запрещающего продавать за рубеж ПО и аппаратуру, содержащие стойкие криптографические алгоритмы, длина ключа для экспортных версий СУБД Oracle искусственно занижалась до 40 бит, что облегчает правительству США чтение шифрованной информации. Признание этого факта содержится, например, в «Oracle Database Advanced Security Administrator's Guide» страница 1-4: «Prior versions of Oracle Advanced Security provided three editions: Domestic, Upgrade and Export, each with different key length. Oracle Advanced Security 10g Release 2 (10.2) contains a complete complement of the available encryption algorithms and lengths, previously only available in the Domestic edition. … The U.S. government has relaxed its export guidelines for encryption products. Accordingly, Oracle can ship Oracle Advanced Security with its strongest encryption features to all of its customers» В последние годы экспортный контроль Гос. Департаментом США был значительно ослаблен, поскольку производители ПО и электроники стали нести слишком большие потери (упущенная выгода), из-за этих ограничений.

Анализ

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

Поиск уязвимостей - долгая и кропотливая аналитическая работа, позволяющая делать выводы об исходных данных на основе шифрованных данных и знания алгоритма (криптосистемы).

Перебор ключей - (второе название «силовая атака», brute force - BF) стандартный способ подбора пароля, заключающийся в генерации очередного значения, шифровании его и сравнении полученного результата с имеющимся хешем. Основную роль в переборе ключей играют вычислительные мощности злоумышленника, таким образом, это универсальный способ для взлома различных шифров, поскольку этот способ не зависит от внутреннего устройства шифра.

Ввиду больших затрат времени и вычислительных средств, к перебору прибегают в том случае, когда остальными методами решить проблему не получается. И даже в случае перебора все равно, пытаются максимально сузить перебираемое множество за счет анализа особенностей конкретного алгоритма.

В дальнейшем будем предполагать, что злоумышленник знает логин пользователя, хеш H и ключ шифрования K.

Если бы криптосистема в Oracle строилась на однократном шифровании, при котором H=DES(X,K), то при известных H и K она бы мгновенно теряла стойкость, поскольку X=DES-1(H,K), и все параметры правой части известны².

В Oracle ситуация сложнее, и при наших допущениях если требуется вычислить пароль Х, то уравнение будет выглядеть так:

Х = DES^-1 (H, K ) (3)

Заметим, что для обратной операции требуется промежуточный ключ K . Т.е., чтобы вычислить значение Х, в данном уравнении недостает значения K =DES(Х, K), которое является промежуточным ключом и не хранится нигде. А вычислить DES(Х, K) нет возможности, потому что X есть Логин||Пароль и пароль, по условиям задачи неизвестен.

Написанное выше означает, что, даже зная ключ шифрования K, можно только вычислить всевозможные значения DES(Логин||Пароль,K) для всевозможных значений пароля, а затем найти в этом множестве подходящее значение. А сделать это можно путем перебора всех возможных паролей, т.е. фактически только путем силовой атаки!

Вот в чем основной фокус криптографической конструкции в Oracle: для вычисления секретного пароля Х необходимо вначале вычислить промежуточный ключ DES(Логин||Пароль,K) для всевозможных значений пароля. Иными словами, теоретическая сложность взлома этой криптосистемы при отсутствии реальных уязвимостей, приближается к сложности силовой атаки на этот шифр.

Такая криптографическая конструкция - удачный пример однонаправленной функции, для которой неизвестна обратная. В итоге остается только перебирать вероятные пароли, сравнивая получившийся результат с образцом.

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

Изучение свойств промежуточного ключа. Несмотря на то, что DES достаточно хороший алгоритм, можно ожидать, что подмножество порожденных значений K' будет небольшим, а также будет обладать специальными свойствами. В результате, из 2⁶⁴ теоретически возможных значений K', в действительности может реализоваться только малая часть. Из значений K' вместе со значением Х можно составить базу данных, чтобы в дальнейшем K' брать из БД и подавать на вход второго узла DES.
Потенциально интересной будет атака с накоплением DES(X,K) с одной стороны, и DES^-1(H,Y) с другой, где Y - некоторое случайное значение (вероятное значение промежуточного ключа). В этом случае возможно как распараллелить эту атаку, так и понизить ее сложность.

Силовая атака

Если аналитическим путем найти уязвимую точку не удастся, то всегда существует метод, называемый силовая атака.

Так, можно, игнорировав значение H, непосредственно приступить к вычислениям X=DES^-1(K',K), взяв генератор случайных чисел в качестве источника K'(расшифровываем некоторое случайное значение K' на ключе K, затем сравниваем результат с Х). Эта атака позволяет сэкономить на операции Х = DES^-1 (H, K') и таким образом ускорить процесс.

По данным [1], программные реализации силовой атаки дают на сегодняшний день скорость 830 тыс. хешей в секунду, используя стандартный Pentium-4 с частотой 2.8 ГГц. Если длина пароля 8 знаков и имя пользователя 8 знаков, то злоумышленник вычислит все возможные пароли приблизительно за 39,3 суток, при этом в среднем он будет обнаруживать пароли на 20-день. Следует подчеркнуть, что скорость в 830 тыс. хешей относится только к 8-байтовым паролям. Более длинные пароли требуют большего времени и больших вычислительных ресурсов.

На сайте http://www.red-database-security.com сравниваются несколько инструментов для силовой атаки на пароли Oracle. Каждый из этих программ шифруют username/password и сравнивают с хеш-значением. Разброс значений скорости перебора на Pentium-4 с частотой 3 GHz такой: код SQL генерирует до 500 паролей в секунду, код на С до 1.100.000 паролей в секунду (наилучший результат). При этом, время, необходимое для полного перебора паролей распределяется так:

5-символьные пароли - 10 секунд
6-символьные пароли - 5 минут
7-символьные пароли - 2 часа
8-символьные пароли - 2,1 дня
9-символьные пароли - 57 дней
10-символьные пароли - 4 года

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

Еще в 1998 г. была запущена в эксплуатацию специализированная ЭВМ для подбора ключей DES, развивающая производительность до 92 миллиардов ключей в секунду. Она способна найти подходящий ключ DES за несколько десятков часов. Стоимость такого устройства около 250 тыс. долларов. Более подробную информацию можно получить по этому адресу.

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

Сводная таблица скорости программных взломщиков

Смотрите здесь или оригинал

Атака по словарю и парадокс дней рождений

Парадокс дней рождений означает следующее: чтобы с вероятностью 0.5 найти человека, с которым у Вас совпадают дни рождения (совпадают месяц и день, год во внимание не принимается), нужно опросить в среднем 253 человека. А для того, чтобы просто найти двух любых людей с совпадающими днями рождения, в среднем, достаточно опросить 23 человек. Различие в 11 раз для результатов этих задач с очень похожими формулировками и послужило причиной парадокса.

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

Использование предварительно вычисленных таблиц обычно ограничено множеством алгоритмов, не использующих случайную привязку. Но привязка в СУБД Oracle не мешает злоумышленнику, поскольку он может построить хеши для заранее выбранной учетной записи (логина). Отличным кандидатом будет логин SYSTEM, который существует во всех БД и гарантирует привилегированный доступ.

По утверждению авторов [1] на стандартном Pentium-4 2.8 ГГц для пароля длиной 8 знаков (217 180 147 158 возможных паролей) предварительные вычисления продолжались в течение недели. В этой конфигурации пароль для этой учетной записи был обнаружен в 98.1% случаев.

Это сильный результат. Но он верен только для паролей длины 8. Принципиально сильным результатом в этом направлении было бы генерация одного пароля для каждого значения хеша. В этом случае, тему безопасности СУБД Oracle можно было бы считать полностью исчерпанной. Однако, это потребует хранилища емкостью 8*2⁶⁴ байт = 134 217 728 Тб- что, по-видимому, никогда не будет реализовано. Реальной уязвимости для длинных паролей не продемонстрировано.

Эквивалентная длина хешей и паролей

Еще один момент касается соизмеримой длины паролей и хешей.

Дело в том, что длина паролей в Oracle может достигать 30 знаков, а длина хеша фиксирована и равна 8 байт, т.е.64 бита. Таким образом, на одно хеш-значение приходится приблизительно 10⁵²/10¹⁹=10³³ возможных паролей в Oracle.

Давайте прикинем эффективную длину пароля, в зависимости от длины хеш-значения. Возможных значений хеш-функции 2⁶⁴, следовательно, надо решить уравнение 57^х=2⁶⁴. В результате получаем х≈11. Этот факт показывает, что практически для всех паролей длиной больше 11 знаков будет существовать более короткий пароль. Следовательно, в результате силовой атаки злоумышленник обнаружит один из кратчайших паролей. Но, поскольку хеш короткого и длинного паролей одинаковы, то пароли можно считать неразличимыми. Следовательно, при длине пароля более 11 знаков увеличение длины пароля не увеличивает время безопасности СУБД, т.е. необходимое злоумышленнику для его нахождения.

Интересно также узнать, а что если Oracle решит отказаться от принудительного преобразования символов к верхнему регистру, то, как это повлияет на эффективную длину? Оказывается в этом случае х≈10! Разница всего в 1 знак.

Для современных хеш-функций минимальная длина хеш-значения обычно находится на уровне 128 бит. Что в этом случае?

А в этом случае 21²⁸ ≈ 57²² ≈83²⁰, что означает, что для хеш-значений 128-битовой длины потребуется 22 знака из 57-знакового множества, либо 20 знаков для 83-знакового (т.е. 20 знаков, если отказаться от преобразования к верхнему регистру).

Ну и, наконец, 30-символьному паролю должен соответствовать хеш длиной

175 бит, если сохраняется Upper() (57 знаков);
191,25 бит, если отказаться от Upper() (83 знака).

Выводы

Подводя итог, следует сказать, что реальной уязвимости на сегодняшний день противники СУБД Oracle не продемонстрировали. Каких-либо уязвимостей в криптографической конструкции не предъявлено. Новых теоретических результатов по вопросу получения несанкционированного доступа к СУБД Oracle тоже нет. Результаты по подбору паролей в [1,3] получены за счет эффективного применения вычислительных средств и осуществляют банальную силовую атаку на хеш. При отсутствии специализированного ПО либо специализированных аппаратных средств, осуществить такую атаку за разумное время невозможно, точнее вероятность успеха ничтожно мала, а время атаки космически велико.

Это подтверждается самими авторами [1], которые не нашли уязвимость в криптосхеме или ее реализации, а всего лишь продемонстрировали очередной вариант силовой. Надо отдать им должное, они честно признают этот факт: «…нельзя сразу указать криптографическую слабость конструкции хеш-функции в СУБД Oracle …» Фактически они подтвердили, что единственный способ на сегодняшний день узнать пароль - это силовая атака (полный перебор).

Стойкость парольной защиты Oracle также подтверждается и известным сайтом, посвященном уязвимостям в СУБД Oracle: «It is not possible to decrypt a hashstring … »

Тем не менее, стоит подчеркнуть, что в системах с повышенными требованиями к безопасности для обеспечения надежной аутентификации следует использовать более сильные средства, чем стандартная парольная защита СУБД Oracle. Интересный вариант - настроить внешнюю аутентификацию и тем самым перенести проблему из СУБД в другое место.

Пользователям можно порекомендовать выбирать пароли, состоящие из нестандартных символов, заключая их в двойные кавычки.

Сравнивая парольные защиты в Oracle и ОС Unix, следует отметить, что ОС защищены слабее. Я имею в виду то, что в основных промышленных ОС - Solaris 8,9, HPUX 10,11, AIX 4,5- в качестве пароля используются только первые 8 знаков. Вы можете произвести эксперимент, и окажется, что, например, для пользователя root, пароли rootroot, rootroot1, rootroot2 и т.д. являются с точки зрения ОС одинаковыми, т.е. одинаково проходными! Так что, если Вы набираете 10 знаков при подключении к серверу, то фактически Вы набираете только первые 8. Спрашивается, имеет ли смысл защищать СУБД, если защита самого сервера слабее? В ОС Линукс и Solaris 10 ситуация с паролями намного лучше.

Варианты усовершенствования парольной защиты сервера Oracle

- От DES следует отказаться в силу малой длины ключа и малой длины блока. Малая длина ключа означает успешность силовой атаки за небольшое время, а малая длина блока означает повышенный уровень коллизий.

Если у разработчиков Oracle есть приверженность к алгоритмам шифрования, то можно взять новый, более совершенный алгоритм AES, пришедший в 2000 г. на смену DES'у. Этот алгоритм допускает вариацию длины блока (128, 192, 256 бит), длины ключа 128, 192, 256 бит и количества раундов (чем больше раундов, тем выше качество шифрования и меньше скорость). Алгоритм AES сертифицирован национальным институтом США по стандартизации NIST и АНБ (Агентство Национальной Безопасности США).

Либо можно выбрать сертифицированную криптографически стойкую хеш-функцию, которых к сегодняшнему дню разработано несколько десятков. В России таким стандартом является ГОСТ Р 34.11, в Европе - RIPEMD, в США - SHA, MD5. Они протестированы компетентными организациями (органами) и приняты в качестве государственных стандартов. Для предотвращения коллизий и сведения к минимуму эффекта от парадокса дней рождений современную длину блока можно установить в 256 бит. По современным оценкам этой длины хватит на сотню-другую лет, при сохранении современных темпов развитии вычислительной техники.

- Конкатенацию логина и пароля следует заменить другим преобразованием, например сложением. Дело в том, что конкатенация приводит к неожиданному эффекту:

SYS @ orcl >create user "o" identified by racle;
SYS @ orcl >create user "or" identified by acle;
SYS @ orcl >create user "ora" identified by cle;
SYS @ orcl >create user "orac" identified by le;
SYS @ orcl >create user "oracl" identified by e;

SYS @ orcl >select username,password from dba_users 
            where username like 'o%' order by username;
USERNAME                       PASSWORD
------------------------------ ------------------------------
o                              8C05BDE49B713CC9
or                             8C05BDE49B713CC9
ora                            8C05BDE49B713CC9
orac                           8C05BDE49B713CC9
oracl                          8C05BDE49B713CC9

Этот пример показывает два факта:

Неожиданный способ порождения коллизий. Т.е. если в базе данных заведен пользователь "ora" с паролем "cle", то в процессе силовой атаки мы можем наткнуться на логин "o" с паролем "racle", в результате чего угадать реальную пару логин||пароль будет совсем несложно, потому что для каждого пароля случайной добавкой (солью) является часть его логина. Таким образом, в целях минимизации числа коллизий следует от конкатенации отказаться.
Зная имена стандартных пользователей sys, system, outln и т.д., противник имеет возможность заблаговременно сгенерировать словарь. Если не весь словарь целиком, то хотя бы из наиболее часто употребительных паролей. В этом случае задача расшифровывания сводится к задаче поиска в массиве заранее вычисленных значений. А в случае, например, побитового сложения логина и пароля, знание имен стандартных пользователей пользы противнику не принесет.

Есть еще одни вариант - по аналогии с ОС - использовать действительно случайное значения "соли". Однако, тогда эту соль пришлось бы где-то в базе данных хранить, а в данной конструкции разработчики Oracle проблему хранения соли элегантно обошли.

- «Двухэтажную» конструкцию Oracle полезно превратить в «трехэтажную», по аналогии со стандартом ANSI X9.17. Такая конструкция существенно усложнит для криптоаналитика атаку с накоплением, основанную на парадоксе дней рождений, а также атаку с анализом промежуточных ключей.

Кроме того, «трехэтажная» конструкция замедлит скорость вычисления хеша, что замедлит скорость силовой атаки, и тем самым повысит стойкость криптосистемы. Это стандартное требование к хеш-функциям, гласящее, что «хеш-функция должна вычисляться медленно». Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Медленный однонаправленный алгоритм не сильно замедлит одноразовое вычисление пароля, при подключении к БД, но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.

- Не игнорировать различие между заглавными и строчными символами. В этом пункте нет вообще никаких принципиальных сложностей.

В настоящий момент количество возможных паролей есть . После отмены преобразования к верхнему регистру множество допустимых символов увеличится с 57 до 57+26=83, и в результате количество возможных паролей возрастет до величины .

Расширение множества допустимых паролей позволит скомпенсировать на десяток-другой лет возможные успехи в вычислительной технике и криптоанализе.

- После вышеописанных изменений криптосхему корпорации Oracle следует подвергнуть сертификации. Это повысит доверие к ПО Oracle. Для такого популярного продукта как СУБД Oracle официальное признание и подтверждение его надежности со стороны компетентных организаций является важным моментом, как при его эксплуатации, так и при продвижении на рынке. В худшем случае, слабое звено будет выявлено, и заменено более стойким.

- В качестве варианта по построению защищенной СУБД, интересно было бы генерировать уникальное значение ключа для каждой инсталляции СУБД. Дело в том, что для некоторых ИС с повышенными требованиями к безопасности очень желательно иметь возможность скомпилировать своего собственного клиента с зашитым в нем уникальным ключом, т.е. клиента, способного подключаться только к своей «родной» БД, оснащенной таким же ключом. Понятно, что обычный клиент со стандартным ключом никогда не подключится к такой БД. Не смотря на все возникающие сложности, предлагаемая конструкция дает сильную гарантию безопасности информации в БД.

Источники и литература

1.обратно	Joshua Wright, Carlos Cid (18. Oct. 2005) An Assessment of the Oracle Password Hashing Algorithm
2.обратно	Брюс Шнайер, Прикладная криптография, Издательство «Триумф» 2003 г.
3.обратно	R. Morris, K. Thompson "Password security: A case history", Communications of ACM, v.22, n. 11, Nov. 1979., pp. 594-597.
4.обратно	Л. Дж. Хоффман "Современные методы защиты информации"(М.: Сов. радио, 1980).
5.обратно	Э. Танненбаум. «Современные операционные системы». М. СПб, Питер, 2002.

На этом можно было бы и закончить, но у этой истории появилось продолжение.

¹(обратно к тексту)

Хеш-функция - это преобразование, вычисляющее из данных произвольной длины некое значение (свертку) фиксированной длины, обычно от 64 до 256 бит. Простейшими примерами хеш-функций являются контрольные суммы, например, CRC32. Хеш-функции бывают криптографические и программистские. Криптографический хеш отличается от программистского двумя свойствами: необратимостью и свободностью от коллизий.

Хеш-функции должны удовлетворять следующим требованиям:

Аргумент хеш-функции может быть строкой бит произвольной длины;
Значение H(M) должно быть строкой бит фиксированной длины;
Хеш-функция должна быть необратимой. Необратимость означает, что если известно хеш-значение X, то вычислительно сложно подобрать M такое, что H(M) = X, т.е. это требование означает, что сложно подобрать пароль по его хеш-значению.
Свободность от коллизий означает, что вычислительно сложно подобрать такие m1 m2, что H(m1) = H(m2), т.е. когда для разных паролей получается одно и то же хеш-значение.

²(обратно к тексту)

Изначально именно так и было сделано в ОС Unix. Когда пользователь подключается к серверу по telnet, то пароль передается открытым текстом на сервер, на сервере пароль складывается с солью, и от этого значения считается хеш, который сравнивается с значением хеша, хранящимся в сервере.

Шифрование паролей в СУБД Oracle

Краткое содержание

Сводная таблица скорости программных взломщиков