Hiding Passwords for Oracle

[oradba]

Does anybody knows how to hide passwords when executing SQLPLUS ?

[John Palmer]

Hi,

If you mean hiding them from appearing in a ps listing because they've been supplied as arguments to sqlplus then instead of running:

sqlplus /

In an interactive session, run:
sqlplus
/
...

In a script run:
sqlplus << EOD
/
...
EOD

Regards,
John

[Steven E. Protter]

Prior post shows you how to script sqlplus, that kind of code is available all over the net.

What you can do is create a deep, dark password vault for oracle.

A fs where only the oracle script user can access. Then you can store passwords there and read them into your script.

When the oracle password changes, you'll have to update the files.

You'll also want to encrypt the files, so that if someone gains root access they can't get those passwords, though if they get root access you're pretty much screwed anyway.

P

[CCIL]

HI1

yous should have the oracle client (8i) , the file tnsnames.ora file should have the entry of entry of Oracle databse listner . then you can issue sqlplus with connect strings i.e name of database & user name , then it will ask for password which can not be seen.

[CCIL]

the exact syntax is

sqlplus username@connect_string
it will ask for password which will not be displayed

[Yogeeraj_1]

hello,

Well, my favorite solution to this is to use an "identified externally" account.
For example, I've set:


NAME TYPE VALUE
------------------------------ ------- --------------------
os_authent_prefix string ops$

in my init.ora. I then:

create user ops$yd identified externally;

This lets me:

$ id
uid=12997(yd) gid=1(other)

$ sqlplus /
SQL*Plus: Release 8.1.5.0.0 - Production on Fri Mar 10 19:28:46 2000
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production

ops$yd@8i> show user
USER is "OPS$YD"
ops$yd@8i>


I do not need a username password anymore (i can still use them but I can always
use / to log in as my). This is perfect for cron jobs, at jobs and the like.
You have to be logged into unix to become that account.

Hope this helps!

Best Regards
Yogeeraj

[Yogeeraj_1]

hi again,

Another way, when on korn shell you can issue

print PASS | oracletool

where 'oracletool' is most of the common oracle ones - exp, imp, sqlplus etc



for example:

print my_pass | exp userid=system file=...

or

print my_pass | sqlplus system @my_script

Or for my lengthy scripts

print "
connect user/pass
select ...
exit" | sqlplus /nolog


Hope this helps too!

Cheers
Yogeeraj

[Ravi_8]

Hi,

oracle> sqlplus username@instance_name
password:

passwd wouldn't be echoed

[Chuck Higgins]

I like your answer Yogeeraj, the one about using ops$.

I have been puzzled by this same question before and have never had a solution that I felt offered good security. My need for this has always been to automate a process with a script, which means that somewhere you need to get a clear text password because there will be no user around to type in the password.

I have considered using a encrypted file, but that means that you need to identify the file name and the encryption key in clear text and it is just one more step to get the password.

I think it makes a lot of sense to get the permissions from the user that is running the script so no password is required. If I was the author of the question, I would give you some points!

Only one problem, which is that the answer is Oracle specific. Maybe there is a similar solution for other DBs such as Solid?

Cheers,

Chuck

[Philippe Cussigh]

Hello,

Just a small comment about the "externally" identified user.
It is a great solution I do appreciate.
The issue is that if you create the OPS$xyz user, any user can create a xyz user on his own system, connect as xyz, then access the database with the connect / sequence.

Oracle can limit the "admin" rigts you can get remotely but the security failure is quite important. Anyway if you have only a limited number of "Oracle client", for instance with application serevers, you can easily restrict in the protocol.ora file the list of TCP/IP addresses which can access the system.

Philippe