Call: +44 (0)1904 557620 Call

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.

[Previous entry: "Flaw hunters pick holes in Oracle patches"] [Next entry: "Some news stories about the josh oracle password paper"]

Josh has released a paper about the Oracle password algorithm

I saw a few days ago that Josh was going to give a presentation about the Oracle password algorithm at the LA SANS conference that is going on this week. A news item by Ken Young titled "SANS reveals Oracle hack" talks about the paper and presentation. The paper is titled "An assessment of the Oracle password hashing algorithm" and it discusses various things about the hashing of usernames and passwords in Oracle. Some of this information has been known for some years by quite a few researchers and Oracle watchers but most likely not by everyone. For example the fact that usernames and passwords are contatenated. I wrote about this a few years ago. Also that the ASCII characters are not case sensitive, again I covered this years ago. The algorithm has been public for 12 years on a newsnet posting by its creator Bob Baldwin and Josh has now enhanced this description to cover the details revealed on a couple of months ago and reported here. Josh talks about how the hashes can be found and also some ideas on protecting the passwords.

The new information is Josh's excellent example of using rainbow tables to crack Oracle passwords. This is a technique where huge numbers of passwords are hashed before hand and stored in files as rainbow tables. Josh shows how an 8 character password can be found in just over 4 minutes.

This is a good technique to find longer passwords that could be much harder to crack with brute force crackers such as orabf but there are also considerations to be made with this technique. The rainbow tables take some time to create and they are created for just one database user. So whilst setting it up to crack say SYS or SYSTEM will give access as anyone in the database its not a universal solution to crack any password for any user as you would need to create tables for all users but that would not be necessary if the SYS or SYSTEM hashes are available. That said it makes it more critical to not reveal any password hashes to anyone. If a hash for another user is revealed where no rainbow tables are available then its debatable whether a brute force crack or creation of rainbow tables is faster.

This is a good paper that summarises the issues but the new idea is to use rainbow tables. I have known about this for some time as Josh sent me a copy of the paper for review and a copy of the tables a few months ago on DVD, thanks Josh! Also i am aware of others who are actively creating tables for all the default users and have been doing so for quite a long time.