[Previous entry: "Alex has released his paper on metalink hacking"] [Next entry: "An interesting post about PeopleSoft and Oracle"]
Steve has added an undocumented sample for fixed JDBC credentials
June 1st, 2005 by Pete
Post to del.icio.us
Post to Furl
I saw Steve Muench's blog entry this morning on orablogs and went over to Steve's site for a proper look as it sounded security related. Steve's post is titled "Providing Fixed JDBC Credentials from Custom Source" and talks about a customer question he has recently received from an Oracle consultant asking if it is possible to provide JDBC connection information in a place other than the bc4j.xcfg file. Steve has added an extra item to his undocumented samples page, number #38 titled "Set Fixed JDBC URL Connection to Custom Value from Alternative Source". In this example Steve has hard coded the connection information in a class called CustomJDBCURLInfoProvider.
I am never convinced about hard coding usernames and passwords inside application source code that is then deployed into a number of locations that are under less control than the configuration file could be - Yes I know that in a lot of clients neither the file or the Java will probably be secured. The Java source can be either reversed quite easily or a string utility or binary editor used to extract the password quite easily. Of course a configuration file does not need to be reversed!, it can be simply read if access is gained. BUT, as I am not an expert in Steve's Java areas it is harder for me to know about the whole security landscape used. My opinion would be that if presented with two choices of either hard coding the password in a configuration file or in the source code, I would choose the configuration file as there are better potentials for securing the file as there is a better chance of centralising it rather than having the password in multiple deployments of the Java classes. That said neither solution is great for strong security - This is no reflection on Steve's example.
If you are concerned with good security then look at password repository solutions, or do not store the password, have it passed in if possible or use solutions such as LDAP. Of course always use the least privilege principle. This means ensuring that the privileges assigned to the user who's password is stored or hard coded is set to the minimums possible, this is sometimes hard to do especially with existing systems but it is worth the effort. If you seriously reduce the privileges to only what is necessary you lessen the risk of an attacker being able to do anything with an account if he learns its password.
