Варианты усовершенствования парольной защиты сервера 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-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.
- Не игнорировать различие между заглавными и строчными символами. В этом пункте нет вообще никаких принципиальных сложностей.
В настоящий момент количество возможных паролей есть
Расширение множества допустимых паролей позволит скомпенсировать на десяток-другой лет возможные успехи в вычислительной технике и криптоанализе.
- После вышеописанных изменений криптосхему корпорации Oracle следует подвергнуть сертификации. Это повысит доверие к ПО Oracle. Для такого популярного продукта как СУБД Oracle официальное признание и подтверждение его надежности со стороны компетентных организаций является важным моментом, как при его эксплуатации, так и при продвижении на рынке. В худшем случае, слабое звено будет выявлено, и заменено более стойким.
- В качестве варианта по построению защищенной СУБД, интересно было бы генерировать уникальное значение ключа для каждой инсталляции СУБД. Дело в том, что для некоторых ИС с повышенными требованиями к безопасности очень желательно иметь возможность скомпилировать своего собственного клиента с зашитым в нем уникальным ключом, т.е. клиента, способного подключаться только к своей «родной» БД, оснащенной таким же ключом. Понятно, что обычный клиент со стандартным ключом никогда не подключится к такой БД. Не смотря на все возникающие сложности, предлагаемая конструкция дает сильную гарантию безопасности информации в БД.
