История вопроса
Оказывается, в Интернете имеется системы парольной защиты СУБД 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. |
Длинные парольные фразы не такая уж редкость. Многие руководства по безопасности рекомендуют выбирать фразу или предложение в качестве пароля, а с приходом в нашу жизнь кодировки Unicode такие фразы легко оказываются более 30 байт. С учетом современных реалий было бы полезно разрешить пользователю ввести фразу достаточно большой длины, например, до 256 знаков.
