Two sets of slides added from Helsinki and Wolverhampton

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.

Two sets of slides added from Helsinki and Wolverhampton

May 21st, 2009 by Pete

I have just uploaded the slides from two recent talks. I gave my Oracle security masterclass in Helsinki for the OUGF last week which went really well and also yesterday I gave my talk "the right way to secure a database" for the UKOUG which also was very well received. The slides are updates of previous talks and as usual are available from my Oracle Security white papers page.

Checking if a password is valid using SQL

May 11th, 2009 by Pete

A question was posted on the Oak table mailing list some time back asking if its possible to validate a users password from within the database without creating a session. One of the replies suggested looking at my PL/SQL based password cracker. I didn't have the time to go further with it at the time as I was very busy. Then two or three of weeks ago someone else posted a question to my Oracle security forum "Verify oracle username and password using sql" that is very similar to the oaktable question.

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:


SQL> grant create session, create procedure to testpwd identified by testpwd;

Grant succeeded.

SQL> connect sys/oracle1 as sysdba
Connected.
SQL> grant select on sys.user$ to testpwd;

Grant succeeded.

SQL> connect testpwd/testpwd
Connected.
SQL> @testpwd

Function created.

SQL>

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:


SQL> select testpwd('SCOTT','TIGER') from dual;

TESTPWD('SCOTT','TIGER')
---------------------------------------------------------------

Y

SQL> select testpwd('SCOTT','BLOB') from dual;

TESTPWD('SCOTT','BLOB')
---------------------------------------------------------------

N

SQL>

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?

The right way to secure a database

May 1st, 2009 by Pete

I have just posted the slides to my recent talk (The Right Method To Secure An Oracle Database) at the UKOUG Northern Server technology day held in my home city of York to my Oracle security white papers page in the usual single slide to one page and size slides to one page format.

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.

Pete Finnigan's Oracle Security Weblog

Two sets of slides added from Helsinki and Wolverhampton

Checking if a password is valid using SQL

The right way to secure a database

May 2009

Archives

Syndication