hide sqlplus pwd
Date: Tue, 3 Nov 2009 09:28:59 +1100
Message-ID: <B1C87DCFE2040D41B6F46ADF9F8E4D9C01D0F1F8_at_CALBBEX01.cal.riotinto.org>
One thing to keep in mind with Windows is that you can view the value of a session's environment variables from another session using Process Explorer from www.sysinternals.com (this can be handy for checking the value of a program's oracle_home etc setting when debugging issues).
Keep this in mind if you grab the password from a manager and temporarily store it in an environment variable.
One way around this may be to pipe the output from the password manager
directly into sqlplus.
I haven't tried this with the output from a Password Manager but have
used it to prevent passwords appearing on the command line. Note that
the person trying to find the password doesn't have to be logged on to
the server, if they have the ability to run (say) psexec remotely
against it.
Regards,
Bruce Reardon
From: Jared Still <jkstill_at_gmail.com> Date: Sat, 31 Oct 2009 23:46:43 -0700
Subject: Re: hide sqlplus pwd
Another method is to retrieve the password from a password manager, and then perform the connect inside the SQL script.
I use PDBA:PWD, but there are also commercial password managers that have a command line interface for use in scripts. Password Manager Pro for instance has this ability.
Here's an example from a CMD file:
set USERNAME=%2%
_at_set DATABASE=%1%
_at_echo off
_at_for /F %%I in ('d:\perl\bin\pwc.pl -username %USERNAME% -instance
%DATABASE%') do (
_at_set NBUPWD=%%I
)
_at_echo on
The password NBUPWD can then be used inside a script to connect.
David Fitzjarrel has already responded with the sqlplus bit, I was just giving an example of how to get the password.
All of my linux scripts work this way, though I have to confess I haven't made that change in this particular CMD script for Windows.
Jared Still
This email is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately and delete this message from your system without first printing or copying it. Any personal data in this email (including any attachments) must be handled in accordance with the Rio Tinto Group Data Protection Policy and all applicable data protection laws.
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Nov 02 2009 - 16:28:59 CST