This content has been marked as final. Show 4 replies
please have your developers look at using the secure external password store (an Oracle wallet) that can be used to store database credentials securely:
note 403744.1 How to Use an External Password Store with the OCI JDBC Driver
Harm ten Napel
thanks for your answer, but I am unsure how will this help? If a user has an External Password Store stored on his client, he can connect to the database even easier, can't he? Wouldn't it mean the user can simply connect like "connect /@prodalias" using sqlplus without even the need to reverse engineer the user/password combination out of the application?
If i read the requirement correctly you basically want to let your users to run the client but without installing the client software on each PC where the innards are exposed.
If changing the way the application connects to the db is out of the question, then you can deploy the client via something like XenApp which removes the need to install it into each PC thus hiding the internals from the users. This still doesn't prevent the cunning from trying to grab the connection info from memory though, but it may make it harder to extract the connection information than having the code sitting on each PC.
Changing the way the application connects is my intention. We're completely redesigning the whole application, so everything's open. The only thing that is not to be discussed is a middlerware. Our developers do not want a middleware.
Application virtualization as you mentioned is indeed a topic. But the point that makes me feel insecure is that users can still "read the memory", so as you already mentioned the nescessary work to get the connection information is indeed higher, but it's not impossible.