Database Reference
In-Depth Information
USER# PASSWORD PASSWORD_DATE
---------- ------------------------- -------------------------
120 47D2AEB8BF7A05C1 15-AUG-13
120 E13FB8116FA03212 15-AUG-13
120 2960E83828FA869D 15-AUG-13
This table still contains the 10g passwords, which will be vulnerable to rainbow tables and crackers alike.
And, more concerning, this table gives an insight into the psychology used by the account holder to generate new
passwords. For example:
apple1 , orange2, lemon3 etc. (large Levenshtein Distance but still predictable)
Using the Levenshtein Distance to judge the mathematical difference between the three passwords is not a good
indicator of the predictability of this sequence, which is one reason by a human attacker does have some advantage
over automated protections.
So, if an attacker can crack these passwords they can predict the next password that hasn't been used yet—as
easy as four bananas. This is why this password history table can only be selected by SYS, as is also the case with
sys.user$
in 12c.
So those are some points on human user password management. For default and app accounts there are some
important points to raise. For instance, a common tactic with default accounts is just to expire their default passwords,
safe in the knowledge that the owner of the account will have to change them in the future. Changing a password from
an application perspective can have a significant overhead in terms of finding all the scripts and hard-coded instances
of the password, i.e., application changes, which the application owners may not be in a position to do without spending
money. A shortcut for the account holder is to use
ALTER USER IDENTIFIED BY VALUES
to update the account password
with the same password's hash—thus unexpiring it but without having to change it. This is relevant to DBSNMP, for
instance, which can be unexpired with the same default password using the
by values
clause. Issues like this raise
the point that any system design should be fault tested on a regular basis. For DB/applications this is pentesting and
auditing. It is a good idea to actually try to gain access into the QA version of production in order to verify the controls.
In summary and in the author's view, the password verification should be turned on by default in 12c.
Levenshtein Distance may be innovative but it is not a panacea in practice. I would prefer password history to be more
intuitive and turned on by default. Using the combination of
PASSWORD_REUSE_TIME
and
PASSWORD_REUSE_MAX,
both
set to
UNLIMITED
as a way to indicate that password history is off, is misleading. An ON/OFF button named “Password
History,” which is turned on by default, would avoid the misunderstandings around this functionality. But now
that you are forewarned about this “gotcha,” we can move on to some interesting crypto reverse engineering issues
that have been circulating privately on the European security scene. A professional contact named Laszlo Zoth has
detailed these next two issues to the author, and his personal website is
http://www.soonerorlater.hu/index.khtml
DBlink Decryption in 12c
We saw in chapter 2 how DBlinks prior to 11.2.0.2 can have their passwords decrypted by a user with
SELECT_CATALOG
role.
select name, userid, utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)),
4353, (substr(passwordx,3,16)))) from sys.link$ where name='TEST_LINK';
The same can be done on 12c but in a different way. It should be noted that the above query shows that the key
used to encrypt the password is included with the cipher text in
sys.link$
.
In 12c this key is replaced with a reference to a position within a magic number stored in the Oracle binary. When
that position is looked up, then the value used for the key can be found, and then the password can be decrypted.
This is quite a clever mechanism, but reverse engineering tools such as IDA Pro allow a skilled user to debug the
Oracle binary and follow its path of execution when decrypting DBlinks (
https://www.hex-rays.com/products/ida/
