[Previous entry: "Tales of the Oak Table - Dave Ensors comments on Oracle security"] [Next entry: "massive data theft from a database in California"]
interesting thread on how to secure a third party application
October 28th, 2004 by Pete
Post to del.icio.us
Post to Furl
I saw an interesting thread on comp.databases.oracle.server entitled Adding some random characters to Oracle password yesterday. This thread is interesting for two reasons. The poster is trying to secure a third party application that he does not have access to source code for and also he is asking a question about an Oracle tool to generate random passwords.
The poster explained that the application connected through a shared account to the database from a separate server and all users then connected via the application and this account. He wanted to secure the shared accounts password and also he said he had heard about an Oracle tool that added random characters to a users password to make it secure. I am not sure what this tool is if it exists but the original question to securing access from a server running an application which uses a shared database account is an old question solved by many people.
The main risk is that the shared account must by default have all database privileges necessary to run any part of the application. This means that if a user is able to get the username and password and connect via a tool such as SQL*Plus then he will have all application privileges. A number of solutions have been suggested, including triggers and VPD. The user is on an older version of Oracle (8.1.6.2) so this precludes some solutions.
The best solution is to ensure that privileges for the shared user are not enabled by default. This means granting all privileges via roles and then enabling those roles that are relevant to the application user as they log in. This would not prevent a user who has found the applications password from enabling them himself. The next step could be to add passwords t0o these roles. This again can be defeated as i showed earlier this year in two ways. The first called issues with password protected roles discusses how it is possible in some circumstances to bypass password protected roles. The short paper also discusses the problem of password leakage on the network for setting roles. Out of interest the same issue occurs for password changes for users. This was discussed in a short paper called Passwords transmitted in clear text on SQL*Net that i wrote.
How can this be resolved? In this case as every connection as the shared user is actually made from one server then this connection from server to database can be tunnelled through ssh. There are two papers on my site that discuss how to do this. If access to the server is restricted then the passwords can be hidden and used for roles and for the shared user. The passwords can be encrypted using a public key encryption scheme and decrypted into server memory when the application is started by the user supplying a pass phrase or the application retrieving to from some other secure source. In this way the passwords can be protected, the users do not have roles until they connect and network connections are encrypted to protect the passwords.
Howard as usual has made some good suggestions. He suggested the use of VPD to protect the data at source and to allow access only when the user connects from the applications server. This is a good idea and could be used in conjunction with the above ideas.
