Где хранятся пароли пользователей в oracle
You can create a password file using the password file creation utility, ORAPWD . For some operating systems, you can create this file as part of your standard installation.
This section contains the following topics:
Adding Users to a Password File
When you grant SYSDBA or SYSOPER privileges to a user, that user's name and privilege information are added to the password file. If the server does not have an EXCLUSIVE password file (that is, if the initialization parameter REMOTE_LOGIN_PASSWORDFILE is NONE or SHARED , or the password file is missing), Oracle Database issues an error if you attempt to grant these privileges.
A user's name remains in the password file only as long as that user has at least one of these two privileges. If you revoke both of these privileges, Oracle Database removes the user from the password file.
Creating a Password File and Adding New Users to It
Use the following procedure to create a password and add new users to it:
Follow the instructions for creating a password file as explained in "Creating a Password File with ORAPWD".
Set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE . (This is the default.)
REMOTE_LOGIN_PASSWORDFILE is a static initialization parameter and therefore cannot be changed without restarting the database.
Connect with SYSDBA privileges as shown in the following example, and enter the SYS password when prompted:
Start up the instance and create the database if necessary, or mount and open an existing database.
Create users as necessary. Grant SYSDBA or SYSOPER privileges to yourself and other users as appropriate. See "Granting and Revoking SYSDBA and SYSOPER Privileges", later in this section.
Sharing and Disabling the Password File
NONE : Setting this parameter to NONE causes Oracle Database to behave as if the password file does not exist. That is, no privileged connections are allowed over nonsecure connections.
EXCLUSIVE : (The default) An EXCLUSIVE password file can be used with only one instance of one database. Only an EXCLUSIVE file can be modified. Using an EXCLUSIVE password file enables you to add, modify, and delete users. It also enables you to change the SYS password with the ALTER USER command.
SHARED : A SHARED password file can be used by multiple databases running on the same server, or multiple instances of an Oracle Real Application Clusters (Oracle RAC) database. A SHARED password file cannot be modified. This means that you cannot add users to a SHARED password file. Any attempt to do so or to change the password of SYS or other users with the SYSDBA or SYSOPER privileges generates an error. All users needing SYSDBA or SYSOPER system privileges must be added to the password file when REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE . After all users are added, you can change REMOTE_LOGIN_PASSWORDFILE to SHARED , and then share the file.
This option is useful if you are administering multiple databases or an Oracle RAC database.
If REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE or SHARED and the password file is missing, this is equivalent to setting REMOTE_LOGIN_PASSWORDFILE to NONE .
You cannot change the password for SYS if REMOTE_LOGIN_PASSWORDFILE is set to SHARED . An error message is issued if you attempt to do so.
Keeping Administrator Passwords Synchronized with the Data Dictionary
If you change the REMOTE_LOGIN_PASSWORDFILE initialization parameter from NONE to EXCLUSIVE or SHARED , or if you recreate the password file with a different SYS password, then you must ensure that the passwords in the data dictionary and password file for the SYS user are the same.
To synchronize the SYS passwords, use the ALTER USER statement to change the SYS password. The ALTER USER statement updates and synchronizes both the dictionary and password file passwords.
To synchronize the passwords for non- SYS users who log in using the SYSDBA or SYSOPER privilege, you must revoke and then regrant the privilege to the user, as follows:
Find all users who have been granted the SYSDBA privilege.
Revoke and then re-grant the SYSDBA privilege to these users.
Find all users who have been granted the SYSOPER privilege.
Revoke and regrant the SYSOPER privilege to these users.
Expanding the Number of Password File Users
If you receive the file full error ( ORA-1996 ) when you try to grant SYSDBA or SYSOPER system privileges to a user, you must create a larger password file and regrant the privileges to the users.
Replacing a Password File
Use the following procedure to replace a password file:
Identify the users who have SYSDBA or SYSOPER privileges by querying the V$PWFILE_USERS view.
Delete the existing password file.
Follow the instructions for creating a new password file using the ORAPWD utility in "Creating a Password File with ORAPWD". Ensure that the ENTRIES parameter is set to a number larger than you think you will ever need.
Creating a Password File with ORAPWD
The syntax of the ORAPWD command is as follows:
Command arguments are summarized in the following table.
Argument | Description |
---|---|
FILE | Name to assign to the password file. You must supply a complete path. If you supply only a file name, the file is written to the current directory. |
ENTRIES | (Optional) Maximum number of entries (user accounts) to permit in the file. |
FORCE | (Optional) If y , permits overwriting an existing password file. |
IGNORECASE | (Optional) If y , passwords are treated as case-insensitive. |
There are no spaces permitted around the equal-to (=) character.
The command prompts for the SYS password and stores the password in the created password file.
The following command creates a password file named orapworcl that allows up to 30 privileged users with different passwords.
ORAPWD Command Line Argument Descriptions
The following sections describe the ORAPWD command line arguments.
This argument sets the name of the password file being created. You must specify the full path name for the file. The contents of this file are encrypted, and the file cannot be read directly. This argument is mandatory.
The file name required for the password file is operating system specific. Some operating systems require the password file to adhere to a specific format and be located in a specific directory. Other operating systems allow the use of environment variables to specify the name and location of the password file.
Table 1-1 lists the required name and location for the password file on the UNIX, Linux, and Windows platforms. For other platforms, consult your platform-specific documentation.
Table 1-1 Required Password File Name and Location on UNIX, Linux, and Windows
PWD ORACLE_SID .ora
For example, for a database instance with the SID orcldw , the password file must be named orapworcldw on Linux and PWDorcldw.ora on Windows.
In an Oracle Real Application Clusters environment on a platform that requires an environment variable to be set to the path of the password file, the environment variable for each instance must point to the same password file.
It is critically important to the security of your system that you protect your password file and the environment variables that identify the location of the password file. Any user with access to these could potentially compromise the security of the connection.
This argument specifies the number of entries that you require the password file to accept. This number corresponds to the number of distinct users allowed to connect to the database as SYSDBA or SYSOPER . The actual number of allowable entries can be higher than the number of users, because the ORAPWD utility continues to assign password entries until an operating system block is filled. For example, if your operating system block size is 512 bytes, it holds four password entries. The number of password entries allocated is always a multiple of four.
Entries can be reused as users are added to and removed from the password file. If you intend to specify REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE , and to allow the granting of SYSDBA and SYSOPER privileges to users, this argument is required.
When you exceed the allocated number of password entries, you must create a new password file. To avoid this necessity, allocate a number of entries that is larger than you think you will ever need.
This argument, if set to Y , enables you to overwrite an existing password file. An error is returned if a password file of the same name already exists and this argument is omitted or set to N .
If this argument is set to y , passwords are case-insensitive. That is, case is ignored when comparing the password that the user supplies during login with the password in the password file.
Oracle Database Security Guide for more information about case-sensitivity in passwords.
Включение пользователей в файл паролей
И так, файл паролей создан. При его создании, в него был включён единственный пользователь SYS, пароль которого вводился при запуске утилиты ORAPWD. Если требуется, чтобы данный вид аутентификации использовался и для других пользователей, то необходимо их так же включить их в файл паролей. К счастью, для этого не надо использовать какие-либо дополнительные утилиты, Oracle сам об этом побеспокоится. Единственное что надо сделать, так это предоставить таким пользователям привилегии SYSDBA или SYSOPER и Oracle сам добавит их в файл паролей. В качестве примера попробуем создать пользователя USER1 и предоставим ему привилегию SYSDBA:
При выдаче пользователям привилегий SYSDBA или SYSOPER следует учитывать, что данные привилегии являются специальным видом привилегий. Они не могут предоставляться пользователю с правом их передачи другим пользователям, а так же не могут быть включены в состав ролей. Рассмотрим это на примере. Выдадим привилегию SYSDBA пользователю USER1 с опцией WITH ADMIN OPTION:
Как видим, ошибок при выдаче привилегий с опцией WITH ADMIN OPTION не возникло. Но не всё так просто как кажется. Теперь создадим пользователя USER2, подключимся пользователем USER1 и попробуем выдать привилегию SYSDBA пользователю USER2:
Возникла ошибка. Просто так предоставить другим привилегии SYSDBA и SYSOPER у простого пользователя не получится. Опция WITH ADMIN OPTION здесь не действует. Необходимо предварительно аутентифицироваться с помощью файла паролей и только тогда можно предоставить привилегии другому пользователю:
В отличие от прав передачи, при предоставлении привилегий SYSDBA или SYSOPER роли ситуация однозначная. Сразу возникает ошибка. Так как данные привилегии могут работать и при выгруженном экземпляре, а роли действуют только при запущенной базе данных, предоставление их роли не имеет никакого смысла:
Просмотр пользователей включённых в файл паролей
В файле паролей на данный момент времени должны присутствовать три пользователя SYS, USER1 и USER2. Как убедиться, что они действительно туда попали? Конечно, можно просто посмотреть содержимое двоичного файла, но есть и более простой путь - это системное представление V$PWFILE_USERS:
Как видно из запроса, в файле паролей присутствуют три пользователя USER1, USER2 и SYS. Представление показывает не только присутствие этих пользователей в файле, но и предоставляет информацию о том, какие из привилегий SYSDBA и SYSOPER были выданы пользователю. Эта информация может быть полезна в дальнейшем при исключении пользователя из файла паролей или пересоздании файла.
Maintaining a Password File
This section describes how to:
Expand the number of password file users if the password file becomes full
Remove the password file
Viewing Password File Members
Use the V$PWFILE_USERS view to see the users who have been granted the SYSDBA , SYSOPER , or SYSASM system privileges. The columns displayed by this view are as follows:
Column | Description |
---|---|
USERNAME | This column contains the name of the user that is recognized by the password file. |
SYSDBA | If the value of this column is TRUE , then the user can log on with the SYSDBA system privileges. |
SYSOPER | If the value of this column is TRUE , then the user can log on with the SYSOPER system privileges. |
SYSASM | If the value of this column is TRUE , then the user can log on with the SYSASM system privileges. |
SYSASM is valid only for Oracle Automatic Storage Management instances.
Granting and Revoking SYSDBA and SYSOPER Privileges
If your server is using an EXCLUSIVE password file, use the GRANT statement to grant the SYSDBA or SYSOPER system privilege to a user, as shown in the following example:
Use the REVOKE statement to revoke the SYSDBA or SYSOPER system privilege from a user, as shown in the following example:
Because SYSDBA and SYSOPER are the most powerful database privileges, the WITH ADMIN OPTION is not used in the GRANT statement. That is, the grantee cannot in turn grant the SYSDBA or SYSOPER privilege to another user. Only a user currently connected as SYSDBA can grant or revoke another user's SYSDBA or SYSOPER system privileges. These privileges cannot be granted to roles, because roles are available only after database startup. Do not confuse the SYSDBA and SYSOPER database privileges with operating system roles.
Oracle Database Security Guide for more information on system privileges
Пароли чувствительные к регистру
Начиная с одиннадцатой версии, в Oracle введена возможность использовать пароли с учётом регистра. Для обычных подключений по умолчанию этот режим включен и определяется параметром инициализации SEC_CASE_SENSITIVE_LOGON:
Файл паролей по умолчанию так же использует пароли чувствительные к регистру. Причём этот режим никак не зависит от установок параметра SEC_CASE_SENSITIVE_LOGON. Продемонстрируем это на примере.
Для начала выключим зависимость паролей от регистра:
Перезагрузим экземпляр. Изменим пароль пользователя USER1 на верхний регистр:
Теперь попробуем подключиться к экземпляру в обычном режиме и с помощью файла паролей:
Как видно, при аутентификации с помощью файла паролей, пароль зависит от регистра независимо от того, что параметр SEC_CASE_SENSITIVE_LOGON выключен.
Если возникает необходимость в том, что бы пароли пользователей, включённые в файл паролей, не зависели от регистра, то необходимо, при создании файла с помощью утилиты ORAPWD, указать опцию IGNORECASE. Попробуем продемонстрировать это на примере. Для начала пересоздадим файл паролей с данной опцией:
Теперь пароли пользователей, помещаемых во вновь созданный файл, не будут зависеть от регистра. Проверим это. Так как файл был создан заново, включим в него опять пользователя USER1 и попробуем под ним подключиться:
Как видно подключение прошло успешно в не зависимости от того, в каком регистре пароль был набран.
Урну с водой уронив, об утес ее дева разбила.
Дева печально сидит, праздный держа черепок.
Чудо! не сякнет вода, изливаясь из урны разбитой:
Дева над вечной струей вечно печальна сидит.
Александр Сергеевич Пушкин
Чуда не вижу я тут. Генерал-лейтенант Захаржевский,
В урне той дно просверлив, воду провел чрез нее.
Аннотация
В статье рассматриваются некоторые собенности парольной защиты Oracle, способствующие несанкционированному проникновению в БД и меры по снижению риска подобного проникновения.
Введение
СУБД Oracle, подобно всем, реально конкурирующим с ней, является старой системой, создание которой происходило, как и продолжается ныне развитие, в рыночных условиях. В этой СУБД, как и у конкурентов, есть целый ряд конструктивных решений, принятых в свое время второпях, и со временем ставших неудовлетворительными. Что-то удается усовершенствовать: например механизмы выделения динамической памяти для текущих нужд СУБД, регулирования доступа к общим ресурсам СУБД или буферизации блоков данных. Однако некоторые заложенные на ранних стадиях развития механизмы или же не удается изменить вовсе (недоразвитое понятие схемы БД) или удается, но с большим запозданием. К числу последних относится механизм парольной защиты пользователей (user) и ролей (role). Особенности парольной защиты Oracle, способствующие несанкционированному проникновению в БД, затронуты в этой статье.
Реализация парольной защиты в Oracle
Основным принятым средством аутентификации (проверки подлинности) пользователя Oracle и включаемой/выключаемой роли является указание пароля. Так, пароль указывается при выполнении соединения с СУБД (например, в SQL*Plus в команде CONNECT), в предложении SQL создании пользователя или в полном определении связи с посторонней БД (database link).
Хранение пароля
Заданный для пользователя Oracle командой CREATE/ALTER USER пароль подвергается преобразованию и попадает в словарь-справочник в виде свертки (password hash). При указании пароля в момент установления соединения с СУБД Oracle заново вычислит свертку и сравнит ее с хранимой в БД. В открытом виде пароли в БД не хранятся.
Увидеть свертки логически можно, выдав например:
Последняя строка в приведенной выдаче является иллюстрацией применения недокументированной, но широко известной возможности Oracle занести в БД на место свертки в БД непосредственное значение:
Фактически это обесценивает привилегию CREATE SESSION, если таковая имеется (соединение все равно невозможно). Возможность занести в БД непосредственно свертку позволяет обладателю привилегии ALTER USER подменить на время пароль, чтобы за законных основаниях войти в систему под чужим именем. Однако если это пользователь SYS, замененный таким образом ему "пароль" не фиксируется в файле PWD.ORA, так что особой проблемы с доступностью это свойство не создает.
Если параметр СУБД O7_DICTIONARY_ACCESSIBILITY имеет значение TRUE (умолчание в версии 8), к трем указанным таблицам может обратиться любой обладатель системной привилегии SELECT ANY DICTIONARY; в противном случае - только владелец SYS.
Алгоритм вычисления свертки пароля
- [1]
- [2]
- К имени пользователя приклеивается справа текст пароля.
- В получившейся строке буквам повышается регистр.
- Символы строки переводятся в двухбайтовый формат дополнением слева нулевым значением 0x00 (для символов ASCII), и справа строка дописывается нулевыми байтами до общей длины 80.
- Получившаяся строка шифруется алгоритмом DES в режиме сцепления блоков шифротекста (CBC) ключом 0x0123456789ABCDEF.
- Из последнего блока результата удаляются разряды четности и полученная строка (56 разрядов) используется для нового шифрования исходной строки тем же способом.
- Последний блок результата переводится в знаки шестнадцатиричной арифметики и объявляется конечным результатом - сверткой.
- Свертка не зависит от регистра букв. Например, пары SCOTT/TIGER, Scott/Tiger, scoTT/TigeR дадут одну и ту же свертку F894844C34402B67.
- Одинаковые склеенные пары имя_пользователя/пароль дают одинаковую свертку. Например, пары SCOTT/TIGER, SCOT/TTIGER, SCOTTTIG/ER дадут одну и ту же свертку F894844C34402B67.
- Свертка не зависит от БД. Например, где бы мы ни создавали БД Oracle, свертка для пользователя SCOTT и пароля TIGER всегда будет F894844C34402B67.
- Используется шифрование DES.
Обход парольной защиты
Не следует забывать, что подсоединение к СУБД может быть выполнено в обход проверки подлинности паролем. В Unix доверительное подключение пользователя SYS, не требующее указания пароля, возможно при работе от имени пользователя ОС, входящего в группу ОС dba, а в Windows - входящего в группу ORA_DBA, но еще при дополнительном условии, что в файлах sqlnet.ora на клиентской машине и на сервере имеется значение NTS для параметра SQLNET.AUTHENTICATION_SERVICES. При заведении ПО Oracle на Windows это значение этого параметра устанавливается автоматически, что часто игнорируется начинающими администраторами Oracle на Windows и составляет одну из наиболее популярных ошибок.
Возможно беспарольное подключение и других пользователей при условии, что имена таких пользователей в Oracle соотнесены именам пользователей ОС или же употреблены в справочнике каталогов LDAP. Устанавливаются такие свойства командами типа:
В любом случае речь идет о передаче задачи аутентификации внешним по отношению к Oracle средам: ОС или серверу каталогов, и ответственность за несанкционированное проникновение перекладывается на них. Иногда (но не обязательно) это позволяет обеспечить даже лучшую защищенность, чем ту, что дает СУБД Oracle.
Пользователи Oracle с подобными свойствами тоже могут обладать привилегией SELECT ANY TABLE, позволяющей читать любые свертки (с учетом оговорки, сделанной выше).
Взлом пароля
А) Сведение алфавита к одним только большим буквам существенно упрощает перебор. Имея в виду 26 больших букв латинского алфавита и 10 цифр, разных паролей длиною n может быть 36n; если же буквы могуг быть и большие, и маленькие, их полное число становится 52, и паролей может быть 62n. (Может показаться, что эти числа чуть преувеличены, так как Oracle не позволяет начинать пароль с цифры, однако такую проверку СУБД делает в момент установления пароля, а это легко нейтрализовать:
Но даже если бы такое ограничение существовало, оно бы не делало погоды в сокращении объемов перебора).
Б) Знание свертки и имени пользователя позволяет сократить перебор вариантов.
В) Свертка вычисляется только на основе имени и пароля, так что сам подбор можно осуществлять в собственной базе, "на стороне", не оставляя следов в исходной базе и не испытывая проблем соединения с ней.
Г) Хотя сложность взлома шифрования DES достаточно велика, по нынешним меркам этот алгоритм уже не считается достаточно стойким.
Ответ фирмы Oracle на слабости парольной защиты
Фирма рекомендует использовать управление паролями с помощью профилей, в частности, часто менять пароль и выбирать пароли не короче 12 символов.
Пример функции проверки выставляемых паролей давно имеется в штатной поставке Oracle в файле utlpwdmg.sql. Пример употребления может выглядеть так:
(Сценарий utlpwdmg.sql не только заводит функцию SYS.VERIFY_FUNCTION проверки выбираемого пользователем пароля, но и определяет парольные параметры профиля DEFAULT, в частности PASSWORD_REUSE_TIME. Чтобы отменить их действие, потребуется выставить командой ALTER PROFILE default : значения парольных параметров в UNLIMITED).
Во-вторых, фирма рекомендует защищать все файлы, где может оказаться значение сверток паролей (см. выше).
В-третьих, фирма советует защищать передачу данных по Oracle Net, и в-четвертых - полагаться на внешние системы аутентификации ("беспарольное", с точки зрения СУБД, подключение, см. выше).
В этом же пояснении фирмы приводится ссылка на находящийся в открытом доступе документ с названием "Oracle Database Security Checklist", говорящем за себя. Документ датирован уже январем 2007 года; знакомство с ним систематизирует многое из рассмотренного выше.
Неизменным пока остается самое уязвимое место в парольной защите Oracle: алгоритм вычисления свертки. Вероятное решение этой проблемы - дождаться версии 11 СУБД Oracle. По неофициальным сведениям в этой версии будет-таки введено различие больших и малых букв в пароле и алгоритм DES заменен на более современный, SHA-1 или AES. Обработка паролей в версиях вплоть до 10.2, вероятно, меняться не будет.
1 Оба стихотворения маститых поэтов, написанные с разрывом в несколько десятков лет, посвящены одной и той же статуе, доныне сидящей в парке близ Екатерининского дворца в Царском селе, расположенном неподалеку от кажется большого города, но без названия, вместо которого на карте находится другой город, всего за 300 лет пять раз принимавший четыре разных исторических названия, два из которых пока что русские, а два - немецкие. Одна из рекомендаций, приводимых в статье - почаще и разнообразнее менять пароли пользователей.
В Linux это можно проверить с помощью tcpdump.
Типичные ошибки, относящиеся к паролям, укажут правильное направление атаки:
ORA_28000: The account is locked Логин заблокирован. | Подождать в течение PASSWORD_LOCK_TIME и повторить попытку или попросить администратора сменить пароль |
ORA-28001: The password has expired Истек срок действия пароля. | При возможности сменить пароль самостоятельно или обратиться за этим к администратору. |
ORA-00988: Missing or invalid password(s) Пароль не набран, либо набран неверно | Используйте двойные кавычки, например alter user scott identified by "!alex" |
ORA-01017: Invalid username/password; logon denied Введен неверный логин или пароль, доступ запрещен. | Проверьте правильность вводимых реквизитов. |
Потенциальными подозреваемыми будут аккаунты, имеющие доступ к этим столбцам.
Существует скрипт who_can_access.sql Питера Финигана (Pete Finnigan), позволяющий найти пользователей, имеющих доступ к этим объектам. Скрипт можно взять здесь.
Таким образом, можно определить пользователей, получивших права SELECT ANY DICTIONARY или SELECT ANY TABLE. Привилегия SELECT ANY TABLE работает только в случае если o7_dictionary_accessibilty=TRUE
Чтобы получать информацию о пользователях, обращавшихся к учетным записям можно включить аудит на DBA_USERS
Но это единственная таблица, которой не повезло больше остальных. На остальные системные таблицы, содержащие столбец PASSWORD, аудит успешно устанавливается:
Доступ к хешам через линки БД
В словаре БД имеются
USER_DB_LINKS | Database links owned by the user |
ALL_DB_LINKS | Database links accessible to the user |
DBA_DB_LINKS | All database links in the database |
V$DBLINK | Synonym for V_$DBLINK |
GV$DBLINK | Synonym for GV_$DBLINK |
LINK$ | таблица, на которую ссылаются все вышеприведенные представления. |
Представления DBA_DB_LINKS и ALL_DB_LINKS являются безопасными, потому что в них отсутствует информация о паролях. В остальных четырех таблицах поле пароля присутствует, что может служить источником утечки информации. Если в системе баз данных применяются линки, то злоумышленник, получивший доступ к одному серверу может переходить от одной базы данных к другой.
Подмена пакетов
- Если имеется объект с таким названием в текущей схеме, то используется он
- Если имеется приватный синоним с таким названием в текущей схеме, то используется он.
- Если в БД имеется общедоступный синоним с таким названием, то используется он.
Обнаружение потенциальных злоумышленников производится запросом:
А обнаружение потенциальных Троянов производится запросом:
Пароли в трассировочных файлах
Получить пользовательские пароли можно из трассировочных файлов.
Так, например, если установить трассировку пользовательской сессии, то можно увидеть, как пользователь выполняет:
В этот момент в трассировочном файле нечувствительно для работающего пользователя появляется:
Пароли и OEM Grid Control
- пароли к базам данных (системные пользователи, наделенные наиболее сильными привилегиями),
- пароли к хостам (чтобы подключаться, когда БД не стартована)
- логин и пароль на металинк.
Злоумышленник, получивший доступ к этому средству, автоматически получит информацию и средство управления всеми БД, листенерами, OAS'ами, хостами и доступом на металинк. Таким образом, OEM Grid Control - один из наиболее интересных для злоумышленника участков и наиболее сильная болевая точка ИС на основе Oracle.
- MGMT_CREDENTIALS2,
- MGMT_ARU_CREDENTIALS (металинк)
- MGMT_VIEW_USER_CREDENTIALS.
Вообще-то, таблиц больше, чем три:
- Логин + пароль для БД, ОС и листенера:
- Логин + Пароль на металинк:
- 15-байтовое случайное число - пароль пользователя MGMT_VIEW, который используется для работы OEMGC, учетная запись создается как expired & locked:
Шифрование/расшифрование этих паролей производится командами sysman.encrypt() и sysman.decrypt(). В БД эти функции присутствуют в виде wrap-кода, но любой желающий может восстановить их текст с помощью трассировки. Рассмотрим их подробнее:
Функции sysman.encrypt() и sysman.decrypt() используют алгоритм 3DES в режиме СВС с дополнением строки до требуемой длины блока по методу PAD_PKCS5.
Принципиальным моментом в encrypt/decrypt является функция вызова ключа GETEMKEY(). Выглядит она примерно так:
Так какой это ключ? Вот какой:
SELECT SEED FROM MGMT_EMCRYPTO_SEED WHERE ROWNUM = 1;
Таблица MGMT_EMCRYPTO_SEED состоит из одного столбца и одной строки и содержит, по-видимому, случайное для каждой БД число. Таким образом, ключ является константой.
- ключ хранится в БД в открытом виде в таблице MGMT_EMCRYPTO_SEED.
- для шифрования используются общедоступные функции encrypt/decrypt.
- кто имеет доступ к словарю БД, тот имеет большой доступ ко всему остальному.
- на три таблицы можно установить аудит.
Внедрение скрытого пользователя
Затем добавляем в представление DBA_USERS (например, с помощью TOAD) одну строку "and u.name!='HACKER'", как показано на рисунке.
Установка параметра инициализации
Для того чтобы начала действовать аутентификация основанная на использовании файла пароля, параметр инициализации REMOTE_LOGIN_PASSWORDFILE должен быть установлен в значение EXCLUSIVE:
Данное значение является значением по умолчанию для данного параметра и поэтому его не требуется специально устанавливать после инсталляции. Если же параметр имеет другое значение, то стоит помнить, что он не является динамическим, поэтому для того чтобы аутентификация основанная на файле паролей заработала, придётся перезагрузить экземпляр:
Подключение с использованием файла паролей
Для того чтобы аутентифицироваться в локальной или удалённой базе данных с использованием файла паролей, пользователь при подключении должен указать этот вид аутентификации. Сделать это можно разными способами. Например, в утилите SQLPLUS для этого используются служебные слова AS SYSDBA или AS SYSOPER, которые могут быть указаны в команде CONNECT или в аргументах запуска утилиты из командной строки:
Некоторые утилиты oracle, такие как RMAN, вообще не требуют указания ключевых слов. Подключение с использованием файла паролей у них идет по умолчанию:
Что же касается сторонних утилит, то тут возможность подключения пользователя с использованием файла паролей полностью ложиться на плечи их разработчиков и зависит от целей, для которых эти утилиты предназначаются. В большинстве случаев такая поддержка, конечно, реализуется, ведь её отсутствие делает, например, невозможным подключение пользователя SYS, для которого вид аутентификации по файлу паролей является единственно возможным:
Хотя в большинстве утилит Oracle возможность аутентификации с использованием файла паролей реализована, работа пользователя в данном режиме подключения обычно не рекомендуется. Исключения здесь составляют только административные действия с базой данных и доступ к специфической служебной информации, например x$ таблицы. Стоит учитывать, что данный вид аутентификации использует совершенно другие алгоритмы подключения к базе данных, в корне отличающиеся от обычных соединений. Например, когда пользователь подключается к базе данных с привилегиями SYSDBA (SYSOPER) ему определяется схема по умолчанию SYS (PUBLIC), а вовсе не схема соответствующая его имени, как это происходит при обычном подключении:
Из-за этого несоответствия могут возникнуть ошибки при доступе к объектам расположенным в схеме пользователя, если в командах не прописана схема или в системе отсутствуют синонимы на объект.
Так как пользователь, соединяющийся с использованием файла паролей, подключается как пользователь SYS, все действия такого пользователя не попадают в основную базу стандартного аудита. Это сильно затрудняет наблюдение за ним. По той же причине триггеры на уровне базы данных не срабатывают для данного вида подключения. Об этом то же стоит не забывать.
Removing a Password File
If you determine that you no longer require a password file to authenticate users, you can delete the password file and then optionally reset the REMOTE_LOGIN_PASSWORDFILE initialization parameter to NONE . After you remove this file, only those users who can be authenticated by the operating system can perform SYSDBA or SYSOPER database administration operations.
Oracle Support подсказал следующие документы:
- Oracle Password Management Policy (Doc ID 114930.1)
- User Passwords Are No Longer Visible In DBA_USERS As Of 11g (Doc ID 735651.1)
Аннотация Администратору баз данных может потребоваться репликация пользователя из одной системы в другую, сохраняя пароль, или восстановить пароль после обновления системы. В старых системах (8.0.5 и ранее), чтобы временно разрешить пользователю входить в систему под другим именем, администратору базы данных или другому привилегированному пользователю потребуется изменить пароль. До 9i даже администратор баз данных не мог предоставлять разрешения на объекты схемы, не войдя в систему как владелец схемы. Поэтому нередко обнаруживалась необходимость сохранять пароли, временно изменять их для входа в систему, а затем восстанавливать старую версию, когда работа была завершена. С появлением прокси-пользователей (8i) и GRANT ANY OBJECT PRIVILEGE (9i) необходимость в выполнении этих шагов была в значительной степени устранена; но администраторам по-прежнему полезно понимать, где и как Oracle хранит пароли пользователей.
Original publication: 2009-06-09
Updated through Oracle 19c: 2019-12-20
Имя пользователя хранится в виде обычного текста, а информация о пароле хранится в виде хеша. Когда пользователь входит в систему, аутентификационная информация хешируется в соответствии с правилами версии пароля. Если сгенерированный хеш и сохраненный хеш совпадают, пользователь аутентифицируется.
Возникает очевидный вопрос: почему Oracle использует хеширование вместо шифрования? Хеширование не является обратимой операцией; но шифрование есть. Последствия этого просты. Поскольку вы не можете перевернуть хеш, вы не можете извлечь пароль из хеша; но, если пароль зашифрован, он может быть незашифрованным (хотя и с трудом, но все же возможно). Теоретически чрезвычайно удачная догадка случайных символов или перебор всех возможных комбинаций может пройти с ложноположительным результатом, поскольку хеш-алгоритмы можно дублировать. Однако простейший алгоритм Oracle дает 18 446 744 073 709 551 616 возможных хэшей. Таким образом, хотя возможно, что две разные строки могут иметь одно и то же значение, вероятность найти одну мала.
II. Алгоритм хеширования и стойкость для 10G и ниже
Б. Алгоритм
Хеширование - это многоэтапный процесс. Сначала имя пользователя и пароль объединяются в одну строку, которая переводится в верхний регистр. Затем эта строка преобразуется в многобайтовое необработанное значение с ведущими нулями для каждого байта. Это необработанное значение затем шифруется стандартным алгоритмом DES с использованием ключа по умолчанию. Последние 16 байтов вывода затем используются в качестве нового ключа для второго шифрования необработанного значения. Последние 16 байтов второго шифрования становятся хранимым хеш-значением имени пользователя и пароля.
В методологии есть несколько заметных недостатков. Во-первых, конкатенация не имеет внешней соли, поэтому пользователи с идентичными именами и паролями, за исключением смещения символов, могут стать одинаковыми при объединении. Например: Пользователь ABCD с паролем EFGH будет объединен в форму: ABCDEFGH. Другой пользователь ABC с паролем DEFGH будет объединен, чтобы сформировать ту же строку: ABCDEFGH. Это открывает (хотя и с чрезмерным потреблением ресурсов) вектор атаки. Кроме того, алгоритм DES устарел по сравнению с современными стандартами шифрования и, как таковой, подвержен вычислительным атакам с достаточными ресурсами, особенно когда атака связана с радужными таблицами. Что еще более важно, принудительное использование верхнего регистра для начальной конкатенации означает, что этот алгоритм не может поддерживать пароли с учетом регистра.
III. АЛГОРИТМ ХЕШИРОВАНИЯ И УСТОЙЧИВОСТЬ ДЛЯ 11G
В 11g добавлен новый алгоритм хеширования, и с этим изменением сохраненный хэш перемещен из столбца PASSWORD в USER $ в столбец SPARE4. Хэш 10g, если он все еще используется, сохраняется в старом столбце PASSWORD, как и раньше. Ни один из этих хэшей не публикуется через представление DBA_USERS. Вместо этого столбец PASSWORD представления возвращает NULL, а новый столбец PASSWORD_VERSIONS указывает, какие типы хэшей пароля хранятся.
В 11g алгоритм хеширования улучшен двумя способами. Во-первых, используется более современный алгоритм хеширования (SHA-1) вместо получения хеша из подстрок зашифрованного вывода. Во-вторых, вместо имени пользователя в качестве соли используется рандомизированная соль. Эти изменения позволяют поддерживать чувствительность к регистру в именах пользователей и паролях.
Хотя алгоритм более надежен, он также упрощен за счет этих изменений. Сначала с помощью рандомизатора генерируется 10-байтовое (20 шестнадцатеричных цифр) значение соли. Затем это значение присоединяется к необработанной версии пароля. Это необработанное значение затем хешируется с помощью алгоритма SHA-1. Результат представлен в виде шестнадцатеричной строки с префиксом «S:» и суффиксом с шестнадцатеричным представлением соли.
Таким образом, в приведенном выше примере запись spare4 может быть разделена на части:
Это хеш пароля: 17F9149EFD0BDD9DBA305D6910D5928640F7727B
Это соль: 29F261D851C58D37FA9A
К сожалению, хотя алгоритм хеширования 11g более безопасен, чем его более старая версия, к тому времени, когда 11g был впервые выпущен в 2007 году, коллизионные атаки на SHA-1 уже были продемонстрированы двумя годами ранее.
D. Использование 12c
Первоначальный выпуск 12c (версия 12.1.0.1) также использовал алгоритм хеширования 11g. Первый набор исправлений для 12c, 12.1.0.2, представил более новый и более безопасный алгоритм.
IV. АЛГОРИТМ ХЕШИРОВАНИЯ И УСТОЙЧИВОСТЬ ДЛЯ 12C (12.1.0.2 И ВЫШЕ)
Использование столбца SPARE4 расширено в 12.1.0.2 за счет включения хэша 12c, а также хэша 11g. Различные хэши обозначаются их префиксами (S для 11g, T для 12c) и разделяются точкой с запятой. Другой тип хэша, для XDB, также может быть включен (с префиксом «H»), но он не связан с входами обычного пользователя и как таковой выходит за рамки данной статьи. В столбце PASSWORD все еще хранятся старые хэши паролей 10g; но ни одна из версий не отображается в представлении DBA_USERS. 18c использует те же алгоритмы и конфигурацию. Сложность алгоритма хеширования 12c приводит к значительно большей хэш-строке: 160 символов, как показано ниже. Из-за длины хэш-строк приведенный ниже код будет извлекать каждую из них по отдельности, а не все в одной строке запроса.
Таким образом, в приведенном выше примере запись spare4 может быть разделена на части:
Это хэш пароля 11g: 7233E3B91B45F6B813BCFFB5D8669167CB4F498D
Это соль размером 11 г: 0642558A8A3BB39948C0
Это хеш пароля 12c: 381A70048CBB5B531196CDD2CB51393E05E3FBFB0CB019DB39AB4AAB717BB23CA7FB2EA0AD4F60B34C38C9B8CF97BB0C6A4A7530362FBF23492FB02139442AB7 58645C9EA1D1E33C33CB9454D0468BF9
Это соль 12c: 58645C9EA1D1E33C33CB9454D0468BF9
Б. Назначение нескольких версий
В приведенном ниже примере с несколькими хешами пароли объединены в следующем порядке: «12c; 10g; XDB; 11g», но их можно изменить в любом порядке. Опять же, в строке хеша не должно быть разрывов строки. Обтекание текстом связано с ограничениями ширины страницы.
VI. ЧУВСТВИТЕЛЬНОСТЬ К РЕГИСТРУ
Как отмечалось выше, хеширование 10g не поддерживает пароли с учетом регистра; но в 11g новый алгоритм может их поддерживать, если в базе данных включена эта функция. Чувствительность к регистру включается и выключается системным параметром sec_case_sensitive_logon. Если TRUE, пароли будут поддерживать чувствительность к регистру (с использованием хеширования 11g / 12c), если FALSE, то нет. Значение по умолчанию TRUE. Начиная с версии 12.1, этот параметр устарел, но все еще поддерживается.
В следующем примере для учетной записи TESTUSER изменен пароль с «testpwd» на «TestPwd». И мы используем условие, определяемое значениями, чтобы гарантировать, что у нас есть только 10g хэш. Сначала мы проверяем статус параметра, затем меняем пароль и проверяем логин пользователя. Затем убедитесь, что пароль смешанного регистра соблюдается на основе настройки V $ PARAMETER, показанной выше.
В следующем примере пароль будет изменен со строчного на смешанный. Обратите внимание, что хэш 10g в поле PASSWORD в USER $ не изменится; но хеш SPARE4 изменится. Таким образом, хотя хэш 10g сохраняется, он недействителен для использования, пока включена чувствительность к регистру и действуют хешированные пароли 11g. Однако, если хэш 10g является единственным доступным хешем, то параметр sec_case_sensitive_logon не применяется к этому пользователю. После подтверждения правильного соблюдения чувствительности к регистру, хеш 11g удаляется, остается только хеш 10g. Учитывать регистр по-прежнему; но пользователь может войти в систему с разными регистрами.
Интересная особенность безопасности возникает, если отключена чувствительность к регистру, когда нет хэша 10g. Если это произойдет, то пользователь будет заблокирован, потому что хеш 10g является единственным хешем, используемым (или может использоваться) для паролей без учета регистра. В приведенном ниже примере тестовый пользователь все еще имеет пароль «TestPwd», как указано выше, но не сможет войти в систему, потому что чувствительность к регистру отключена.
VII. ПРАВИЛА ВЕРСИИ ПАРОЛЯ SQLNET.ORA
В 11gR1 файл SQLNET.ORA получил новый * параметр: SQLNET.ALLOWED_LOGON_VERSION. Хотя этот параметр не влиял напрямую на хеширование паролей; это может создать несовместимость управления версиями, в результате чего пользователь с действующим паролем не сможет войти в систему. То есть, если параметр был установлен на 10 или 11, то можно использовать только 10 г хэшей пароля без применения критического обновления для клиента. С ЦП можно использовать хэши 10 г или 11 г. Если для параметра установлено значение 12, то будет работать только хэш 11g, поскольку поддерживается только протокол 11g.
12cR1 расширил эту функциональность, разделив параметр на два: SQLNET.ALLOWED_LOGON_VERSION_CLIENT и SQLNET.ALLOWED_LOGON_VERSION_SERVER. Параметр «client» определяет, какие протоколы поддерживаются при подключении в качестве клиента. Параметр «сервер» определяет, какие протоколы поддерживаются при получении соединений в качестве сервера. В обоих случаях управление версиями будет влиять на то, какие версии хеширования будут использоваться при аутентификации. 10 или ниже будет поддерживать любой из 3 алгоритмов хеширования паролей. 11 будет поддерживать только хеши 11g и 12c. Установка параметра на 12 может немного ввести в заблуждение, потому что это приведет к принудительному использованию клиентов 12c, но по-прежнему разрешит хэши 11g. Чтобы принудительно использовать хеширование 12c, параметр должен быть установлен в 12a.
Как отмечалось ранее, начиная с 12cR1, параметр базы данных sec_case_sensitive_logon не рекомендуется в пользу использования параметров SQLNET.ORA для управления поддерживаемыми алгоритмами хеширования.
* В 10gR1 Oracle представила параметр SQLNET_ALLOWED_LOGON_VERSION, который позже был заменен на SQLNET.ALLOWED_LOGON_VERSIONS. Однако, поскольку был доступен только один алгоритм хеширования паролей, этот параметр не имел никакого отношения к использованию хеширования паролей.
VIII. СПЕЦИАЛЬНЫЕ ФОРМАТЫ
У некоторых пользователей вообще нет хэша, вместо этого они хранятся с фиксированными значениями.
Как указано выше, эта статья не является руководством по взлому учетных записей пользователей Oracle. Демонстрации показывают изменение пароля пользователя. Однако эти изменения предполагают, что пользователь DBA существует с необходимыми привилегиями, уже предоставленными законными способами. Следующие команды, если они выполняются SYS, создадут такого пользователя; а также соответствующий тестовый пользователь, использованный в приведенных выше примерах.
Хотя администратор баз данных может иметь возможность или даже право изменять пароль пользователя, это не означает, что он или она должны это делать, поскольку могут возникнуть нежелательные последствия.
Администратору базы данных Oracle часто приходиться выполнять специальные операции, например, такие, как завершение или запуск базы данных. Поскольку исполнять их должен только он, а никто другой, его учётная запись требует безопасной аутентификации. Существует несколько способов аутентификации. Кроме использования стандартной аутентификации по словарю, для администратора базы данных доступны ещё три способа:
- Аутентификация операционной системы
- Аутентификация на основе файла паролей
- Устойчивая аутентификация на основе сетевой службы, такой как, например Oracle Internet Directory
Все три последних метода аутентифицируют административного пользователя даже тогда, когда база данных ещё не запущена.
Как известно, административные привилегии, которые требуются для выполнения основных операций с базой данных, предоставляются через две специальных системных привилегии SYSDBA и SYSOPER. Эти привилегии дают пользователю доступ к экземпляру даже тогда, когда он остановлен, и могут рассматриваться как специальные типы соединений, позволяющие выполнять команды, привилегии на которые не могут быть выданы обычными средствами.
Для аутентификации таких привилегированных пользователей, Oracle может использоваться специально созданный файл паролей. Чтобы данный метод аутентификации заработал, необходимо выполнение трёх условий. Должен быть правильно установлен один из параметров инициализации, файл паролей должен быть создан, в файл должны быть добавлены учётные записи пользователей имеющих привилегии SYSDBA и SYSOPER.
Рассмотрим более подробно этот процесс. Так как большинство примеров будет производиться локально, от имени пользователя операционной системы oracle, временно отберём у него группу dba, чтобы его аутентификация в базе данных не происходила на основе операционной системы:
Здесь стоит упомянуть, что аутентификация операционной системы является превалирующей над аутентификацией на основе файла паролей.
Создание файла паролей
По умолчанию файл паролей создаётся в процессе установки Oracle Database помощником по конфигурированию сервера базы данных (DBCA). В системе UNIX файл имеет формат имени вида orapwORACLE_SID и располагается в каталоге ORACLE_HOME/dbs. В Windows, файл будет называться PWDORACLE_SID.ora и находится в каталоге ORACLE_HOME\database.
Ниже предоставлены различные примеры названий такого файла:
Если файл паролей, по каким то причинам отсутствует или требуется его пересоздание, то можно использовать утилиту ORAPWD. Синтаксис этой команды имеет следующий вид:
Аргумент FILE задаёт имя файла и путь файла пароля, ENTRIES – максимальное количество учётных записей в файле, FORCE – задаёт флаг, который отвечает за генерацию ошибки, если файл с таким именем уже существует, IGNORECASE – позволяет включать, выключать пароль, зависящий от регистра.
Рассмотрим более подробно на примерах создание файла паролей. Для начала определим наличие файла:
В системе присутствует файл паролей orapworcl , который был создан по умолчанию при установке. Удалим его и создадим новый:
Новый файл создан. В него добавлен пользователь SYS , пароль которого запрашивался при запуске утилиты. Если попытаться повторить процедуру создания файла снова, то будет сгенерирована ошибка о том, что такой файл присутствует, и что его надо переименовать или удалить:
Чтобы подавить такой вывод ошибки и пересоздать файл, необходимо при запуске orapwd указать опцию force=y:
Данная опция может быть полезна в пакетных командных файлах.
Читайте также: