Issue with clear text password in Shell script

Sadly, all you can do if you need to provide credentials (versus working with the current OS user) to connect to Oracle is to obfuscate. As soon as you start the DB process, e.g. using sqlplus, you need the plain text password. And so you can store the password in an "encrypted" way in a file or the batch file itself, but also have to show the encryption method somewhere, which usually results in something less obvious only.

Thanks for quick update. In that case how security and compliance will be handled as clear text password is always a threat.
Also to encrypt and decrypt some extra software or coding is required which is not allowed in our platform.
IS there any way by which clear text password cannot be used.

As said, if you can use the current OS user to connect, which requires to have some way of keeping user credentials in sync, then there is no need for a password. Otherwise security is improved by only allowing to execute the script, not read it, by setting only X privilege for others.

which platform? you could think about providing a background service which is connected to ORACLE and handles database requests from client scripts.

Sara

@sara: wouldn't that service need to use the same password to connect to oracle ? seems that would move the problem to a different piece of software.

clear text when it comes to a password used to initiate a client connection is something you cannot avoid. encrypting the password would require the client software to be able to decrypt which is pretty much the same as using it unencrypted. at best, you can store the password in a file that only some system users can read, refrain from using it in the command line which is easy to hack, and use unix sockets or ssl to make it less easy to sniff.

i second qlemo : it is much better not to use a password at all if possible. if you're on the same machine as oracle, you can instruct oracle to allow passwordless access to a unix socket from a specific user.