Database Reference
In-Depth Information
ORA-06512: at "ORDSYS.ORD_DICOM_ADMIN_PRV", line 479
ORA-06512: at "ORDSYS.ORD_DICOM_ADMIN_PRV", line 8232
ORA-06512: at "ORDSYS.ORD_DICOM", line 756
ORA-06512: at line 1
A similar bypass can be carried out using utl_http.request .
What this shows is that redaction is not quite mature yet. New technology often has bugs. Also, trying to hide data
is often a red rag to a bull as far as the infosec community goes. However, redaction is a good feature idea, and with
the patch updates is likely to become popular in high-security environments.
12c Passwords and Cryptography
Passwords in Oracle DB still use the concept of checksumming the human plaintext to a one-way hash and comparing
that hash to one that was prepared earlier and stored within the database to verify the plaintext is indeed the user's
correct password. The main attack is to first gain the hash and then guess the password and see if the guessed hash is
the same.
Step 1 can be achieved by this query returning the 10g password and 11g/12c password hashes.
SQL> select password, spare4 from sys.user$ where name='SYS';
PASSWORD
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
FAEBD85538E5908F
S:F10A0203B7DD417B3DA06319BA93AB644CFCCB13A7B7C18D946BB02EDC17;H:230832521013EC0
C134C4B3A247C1D75
The process of guessing the password normally takes a long time depending on how well the password was
chosen, but it will always be found eventually. Therefore, there are three main areas of protection for user account
passwords.
1.
Hide the hash so an attacker can't find it.
2.
Choose an unpredictable password that is hard to guess.
3.
Change the password before an attacker with access to the hash is likely to be able to guess
the password.
Hiding the hash is not a great protection, and commonly known as “security by obscurity.” It has its uses
but does not afford strong security. The reason for this is that it is quite easy to find a hash, as they are generally
standard-length “random” strings which can be grep'd for. Lessons from the science of lock design have made most
practitioners agree that a trustworthy system should be able to survive its design being made public and only the
key being kept private. The “key” to the lock in this sense is the user's plaintext password. For those interested in the
history of this concept I recommend reading about the Bramah Lock Challenge and how American A.C. Hobbs picked
the lock at the 1851 Great Exhibition at the Crystal Palace in London, and then while living in London published his
famous article stating that lock designs should be published in order to help make them more secure and verify that
their design is truly secure. This is still a matter of debate. Either way, number 1 does not work very well in the author's
experience.
Number 2: Choosing an unpredictable password is very effective but difficult to enforce. Complexity is used to
provide unpredictability, but no control for uniqueness is currently available in Oracle database.
 
Search WWH ::




Custom Search