I am looking for suggestions. I want a way to connect to Oracle database without hard coding username/password. I have tried Oracle Wallet and it's not working. Does anyone have an alternate solution other than storing it in an external file?

Bit of a late answer but another option could be to store the username and password in environmental variables. I personally store database information in an external configuration file and store the path to this configuration file in an environmental variable (although in reality its a bit more in depth than how I've described here). In a web environment, this makes it easy for me to control which configuration file a particular site should use when multiple sites use the same scripts / modules.

Is the configuration file stored outside of the web server? If someone bypasses the web page via command injection, for example, can they access the configuration file and steal the credentials? Our main goal is to have no access to credentials stored anywhere.

It is stored out of what I would describe as "web root". In recent projects I design the file system into two parent directories, private and public, public being where the domain points at.

I understand your concern is injection attacks, specifically command based. My advice would be to perform vigourous validation of all user supplied parameters, especially those that are used in system calls. Prevent an attack in the first place. As you are probably already aware, if there is a vulnerability in this area, you have plenty of other things to worry about than just your database data, although your database data is likely the most critical. As far as I can invisage, no matter what you do, an attacker would be able to work their way to your credentials one way or another, even if stored "outside of the web server".

To be OTT, perhaps you could also not make it obvious what and where the database credentials are, encrypt them, store them amoungst other data, don't directly refer to them under the database namespace, don't directly access them when connecting etc. Make it as difficult as desired for the attacker to reach, you could even include traps that notify you of suspicious behaviour and give you time to act.

But if an attacker has the ability to run their own / modify code, then they could easily connect to the database in the manner you do / dump parts of the database they require.