IMHO по любому не стоит полагатся на фришные СУБД в вопросах безопасности.
Способ, описанный уважаемым Проходящим, конечно что то, но используя фришные же инстументы легко поправить имя роли прямым редактированием *.gdb файла :(
Не говоря уж о том, что можно посмотреть имя пользователя и перебить хеш пароля в isc4.gdb на хеш от известного пароля.

Даже не знаю сколь-нибудь секьюрные СУБД.
У Оракла, к примеру, есть встроенные средства шифрования ХП, и что? Никого это не останавливало - читал, ломают :(

Выход IMHO один - криптовать критичные данные, причем желательно на стороне клиента (в БД передавать уже шифрованые). Конечно некоторые тормоза и геморрой :(
Зато, к примеру 128 ключа большинству известных алгоритмов дадут стойкость на ближайшие десятилетия при оптимистическом взгляде на развитие вычислительных мощьностей. При пессимистическом/реальном на десятки в дестках степеней лет. ;)

Впрос секьюрности не так прост, как кажется.
Конечно, если в БД хранится зарплата, то крипт там может быть весьма простым, если конечно он вообще там нужен.
Другое дело, если там нечто этакое...
Тут отмазки с задавленным админом не пройдут. Все пароли в серьёзной конторе выдаются специальным человеком и ОБЯЗАТЕЛЬНО хранятся в опломбтрованном несгораемом сейфе. Желательно в другом помещении.
Опять же для криптования серьезные организации используют широко известные, документированные алгоритмы.
Вновь пришедшему админу, после получения допуска, необходимо льшь ввести ключ :)