Call: +44 (0)7759 277220 Call
Blog

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: "The Oak Table book should be off to print"] [Next entry: "Hiding password hashes and a new sha1 Oracle password cracker"]

Belated Christmas wishes and a happy new year to all readers



Well it has been a while since my last blog entry - almost two weeks in fact, xmas added onto heavy work loads all gets in the way of blogging...:-)

I still have a backlog of things to blog about so watch out for these in the new year, i cannot promise to blog much between now and next week as I have a lot of work to fit in as well as the new years celebrations!!

I just saw Marcel-Jan's post on my Oracle Security Forum titled "Twitter banned passwords" and it piqued my interest. It is not Oracle security related but it is relevant and not because I also use twitter but because its a good idea. When setting a new password the system should stop you from setting stupid passwords no matter the system. The Oracle database can also do this for you BUT you need to do the work to set it up. The check can be added as part of the password management in profiles; specifically by defining a password verification or complexity function that includes rules to stop weak passwords being set. The standard function supplied by Oracle includes a simple if(password==bad val1 or password==bad val2.... type code.

I usually recommend my clients to create a more proper complexity function that matches the password policies defined in their own access and use policies. This would normally include length, character set, change requirements, lack of simple passwords etc. One of the things we do is to build a table in the database containing all the weak passwords and then the password complexity function checks that any new password does not exist in this table. This allows a much much bigger list of passwords to check against that should not be used.

This is one of the problems with the Oracle database; this stuff is not turned on by default. Simply, you need to do the work. This is a recurring factor of Oracle security; Oracle security is not simply about following checklists or applying CPU's (Critical Patch Updates), it's a lot more. Securing a database is much more about the detail and the configuration. The other problem is that in databases a solution is often not simple. A weak password is a good example. It sounds simple; set it to a strong value but its more than that, you also need to define strong and then enforce strong, you should also limit the chance of abuse and also record abuse attempts. This means setting password management, complexity, fixing the password, audit and more. Complex but complete solutions are needed. Back to the post by Marcel-Jan; this post shows good advice from Twitter, you should use the same ideas in your Oracle databases but remember you need to do the work. That doesn't mean that you cannot steal the material from twitter's article wink, why not take the list of common passwords for twitter. Just because they are common for twitter doesnt mean that they are not common for all other platforms. People are people, are people; and they choose passwords not the software they are used on; this is where we come in and make the software help choose or rather stop some choices from being made. The article Marcel-Jan references is titled "370 Passwords You Shouldn’t (And Can’t) Use On Twitter" and the password list is here.