Pete Finnigan's Oracle Security Weblog
This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.
So last weekend I spent 15 minutes extracting the code from the PL/SQL cracker and making it into an installable function. I have created a function called "testpwd" and its available in a file called testpwd.sql and also available via my Oracle security tools page. The function is easy to use. Simply create a user, grant CREATE SESSION, CREATE PROCEDURE and as SYS GRANT SELECT ON SYS.USER$ to the user and install the function. Then test it. The set up is shown here:
Then its simple to test the function. Imagine you want to verify that SCOTT's password is TIGER - which it is in this database then the function simply returns "Y" and then if a wrong password, in this case BLOB is passed the function returns "N". This means that the function can be used to verify passwords. Here is the sample test:
We can now do what is possible inside the password verification function but outside that function. If you change passwords and want to check whether the same password is reused in a password verification function this is done because both the old and new passwords are available to test. This is not the case anywhere else and sometimes it is desirable to be able to verify old and new passwords.
Hopefully this function is useful?
This was an interesting talk and I wanted to focus just on one thing; this is the importance to start any security project to secure an Oracle database with the "data" itself not simply follow a checklist. Checklists are fine but they should not be a starting point if you want to "secure data". A checklist in this case focuses on the Oracle software settings not your data so, for instance if you followed every step in the CIS benchmark and it would take a long time, would the key data (say your credit cards) you want to protect be protected? - in general the base level of security has definitely risen in the database, there is no doubt, but the specific data you want to secure has not had any specifc security settings applied to it.
This is the point, checklists will help with general hardening but they wont specifically - specifically is the keyword - help with securing your key identified data. So the message is start with the data, understand where it it, how it "flows", how its used, who uses it and then formulate a plan to secure it; checklists can be part of the plan but start with the data.