Шифрование паролей в СУБД Oracle. Часть 2

2007 г.

Шифрование паролей в СУБД Oracle
Часть 2

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

История вопроса

Оказывается, в Интернете имеется информация одного из разработчиков системы парольной защиты СУБД Oracle:

«… Когда я был руководителем проекта Trusted Oracle, то я спроектировал алгоритм, который использовался в версиях 6, 7 и более старших. Я представил детали на симпозиуме Bay Area Trusted System, и после этого я не слышал, о том, чтобы они была опубликована где-либо еще. Вот некоторые детали, которые я помню.
Цели проектирования:

Должен работать со всеми терминалами.
Некоторые терминалы оснащены только заглавными буквами, поэтому парольный алгоритм должен игнорировать различие между заглавными и обычными вариантами. Пароли Tiger и tiger должны восприниматься как один и тот же пароль.
Имена пользователей и пароли должны допускать не-ascii кодировку.
Символы имен и паролей конвертируются в 16-битовые значения, перед дальнейшей обработкой. У ASCII-символов старший байт 0.
Если различные пользователи используют один и тот же пароль, то хеш-значения таких паролей должны различаться.
Должны поддерживаться длинные пароли.
По моему мнению, логин и пароль могут быть по 40 знаков каждый.

Боб Болдуин,
Директор департамента разработки компании Los Altos Technologies, Inc. bald...@lat.com»

Наконец-то стало понятно, почему в СУБД Oracle игнорируется различие заглавных/строчных букв: «Некоторые терминалы оснащены только заглавными буквами… ». Однако все равно странно, почему разработчикам Unix'ов такие терминалы не попадались? ;-) Или почему наличие таких терминалов нисколько не помешало им использовать заглавные/строчные буквы как различные символы? Хотя присутствие 26 дополнительных символов принципиально ничего не изменит в защите, но тем не менее очевидно, что их присутствие увеличит затраты злоумышленника на реализацию силовой атаки, а это всегда хорошо!

Цель 3 - «Если различные пользователи используют один и тот же пароль, то хеш-значения таких паролей должны различаться» хорошая идея, которая в СУБД Oracle обрела весьма своеобразную реализацию. Очевидно, что реализация значения привязки в СУБД Oracle злоумышленнику ничем существенным помешать не может.

И еще одна неувязочка: у Болдуина, судя по его ответу, длина логина и пароля может достигать 40 знаков, но в реальной БД это не так. В реальной жизни при длине пароля 31 знак и более возникает ошибка ORA-00972: identifier is too long:

SQL >alter user sys identified by a234567890123456789012345678901;
alter user sys identified by a234567890123456789012345678901
                             *
ERROR at line 1:
ORA-00972: identifier is too long

SQL >create user a234567890123456789012345678901 identified by x;
create user a234567890123456789012345678901 identified by x
            *
ERROR at line 1:
ORA-00972: identifier is too long

В объяснении ошибки говорится:

Cause:	The name of a schema object exceeds 30 characters. Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames.
Action:	Shorten the name to 30 characters or less.

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

Длинные парольные фразы не такая уж редкость. Многие руководства по безопасности рекомендуют выбирать фразу или предложение в качестве пароля, а с приходом в нашу жизнь кодировки Unicode такие фразы легко оказываются более 30 байт. С учетом современных реалий было бы полезно разрешить пользователю ввести фразу достаточно большой длины, например, до 256 знаков.

Что могли знать разработчики в 1993 г. о хеш-функциях?

Исторические дискуссии о хеш-функциях восходят к 1953 г. (IBM) и описаны у Д.Кнута в его «Искусстве программирования», изданной в 1973 г.

В 1977 г. хеш-функции были классифицированы как независимый класс криптографических приложений в работе J. Carter M. Wegman "Universal classes of hash functions". В 1978 году М. Рабин (M.Rabin) ввел в употребление понятие однонаправленной хеш-функции, построенной из алгоритма шифрования. Десятилетие с 1980 заполнено работами Р.Меркля (R.Merkle), Домгард (Damgård), Райвест (R.Rivest) и ежегодными конференциями Eurocrypt.

В результате к 90 году появились наиболее известные из хэш-функций - MD2, MD4, MD5 и SHA, которые были оформлены в виде стандартов RFC. Так, в августе 1989 автором J. Linn выпущен документ RFC 1115, в котором были описаны два алгоритма: Message Authentication Code и RSA-MD2 Message Digest Algorithm. RFC1115 продержался 3 года и в апреле 1992 ему на смену пришел RFC 1319, в котором была описана новая обновленная версия MD2.

Хеш-функции семейства MD (message digest) разработаны B.S. Kaliski и Роном Райвестом в 1989-м, 90-м и 91-м году соответственно и утверждены в качестве стандартов, например RFC 1319, "The MD2 Message Digest Algorithm". (http://www.rsasecurity.com/rsalabs/node.asp?id=2253)

Тогда же, в апреле 1992 г. появился RFC 1320 «The MD4 Message-Digest Algorithm», который заменил собой RFC 1186 от октября 1990 The MD4 Message Digest Algorithm.

Так что недостатка в информации у Боба Болдуина не было.

На сегодняшний день криптографами разработаны следующие хеш-функции: MAC, MASH, MDC, RIPEMD, SHA, MD2, MD4, MD5, детальную информацию о них можно найти в [2] и в Интернет.

Российское законодательство требует использования российских алгоритмов шифрования и генерации хеш-значения для ПО, использующегося в государственных организациях. На сегодняшний день таким стандартом является ГОСТ Р34.11-94, разработанный совместно ГУБС ФАПСИ и ВНИИС, принятый и введёный в действие Госстандартом России 23.05.94. Размер хеш-значения 256 бит. Ниже приведён текст сообщения Боба Болдуина:


From:		Bob Baldwin - view profile

Date:		Thurs, Jul 8 1993 5:49 pm 	

Dave Trahan wants to know the Oracle password algorithm so 
he can check for weak passwords.  When I was the project 
lead for Trusted Oracle I designed the new password algorithm 
that is used in versions 6, 7, and later.  I presented the 
details at a Bay Area Trusted System Symposium so I am not 
revealing any information that is not already in the puiblic 
domain.  Here are some of the details as I remember them. 

Design Goals: 
1. Must work with all terminals. 
   ===> Some terminals do not have lowercase letters, so 
        the password algorithm ignores differences between 
        upper and lower case!!!  The passwords "Tiger" 
        and "tiger" map to the same value. 

2. Must support usernames and passwords that include non-ascii 
   characters. 
        The username and password are converted to 
        16 bit per character representation before any processing 
        is done.  Ascii characters have the high byte zeroed. 

3. If different users have the same password, then the one-way 
   hash value (encrypted value) for the passwords will be different. 

4. Long passwords are supported. 
        I believe that usernames and passwords can both be 40 chars. 

Implementation: 
1.  Upshift password, convert to 16bits per character, and place 
    result left justified in an 80 byte array of zeros. 

2.  Using DES in cipher block feedback mode compute the CBC checksum for 
    the 80 byte password array using a fixed secret password (you can find 
    it in the code if you look hard enough).  The result is used as the 
    key for the next step ignoring parity bits to produce the a 56 bit 
    key from the CBC. 

3.  Upshift password, and convert to 16bits per character, and place 
    result left justified in an 80 byte array of zeros. 

4.  Using DES in cipher block feedback mode compute the CBC checksum 
    for the 80 byte username array using the key generate in step 2. 

5.  Convert the CBC checksum from step 4 into a printable string with 
    the obvious algorithm. 

                --Bob Baldwin 
Director of Development                 We provide the best solutions 
Los Altos Technologies, Inc.            to our customers key security 
bald...@lat.com                                problems.

Содержание