Data Dictionary Views and Password Columns
There are numerous views and tables within the data dictionary that have a password column in clear text or in hashed form. The query below demonstrates that there are many ways to deriving the hash values for the user passwords. Once the hacker has the hashed value, the race is on to crack the hash value to determine the password to the database.
SQL> select owner, table_name from dba_tab_cols where column_name = ‘PASSWORD’;
OWNER TABLE_NAME
—————————— ——————————
SYS KU$_ROLE_VIEW
SYS KU$_USER_VIEW
SYS KU$_PSW_HIST_LIST_VIEW
SYS KU$_10_1_DBLINK_VIEW
SYS KU$_DBLINK_VIEW
SYS SCHEDULER$_CREDENTIAL
SYS EXU8PHS
SYS EXU8ROL
SYS DBA_USERS
SYS USER_DB_LINKS
SYS _BASE_USER
OWNER TABLE_NAME
—————————— ——————————
SYS USER_HISTORY$
SYS LINK$
SYS USER$
WKSYS WK$$HTTPAUTH
WKSYS WK$HTTPAUTH
WKSYS WK$_HTTPAUTH
SYSMAN MGMT_TEST_PROP
SYSMAN MGMT_BAM_DATA_HUBS
19 rows selected.
Oracle 11g stresses more than ever the need for tighter security. One of the best ways to thwart hacking is by enforcing a stronger security against Oracle’s data dictionary. Having access to the data dictionary should be on a need to have basis. DBAs should not grant the select any dictionary role or select catalog role to developers. If for some reason the developers need access to the data dictionary, only subsets of views should be considered for grants. When the request is made to have select privileges against any views with the password column, extra caution should be exercised since it makes it easier for hackers to attack the system. This is especially the case if strong passwords are not enforced.