Comments on: Procedural SQL*Plus and Password Encryption

By: Vivek

Vivek — Fri, 08 Mar 2013 14:00:38 +0000

Give me Guidance about SQL *PLUS with Oracle.how to use and configure these stuff, i m student if u don’t mind waiting for reply

By: Kyle Hailey

Kyle Hailey — Mon, 02 Jan 2012 19:06:48 +0000

@wski Thanks for stopping by and sharing your script. As far as I can tell your script is mainly a SQL script store with the pivotal part being:


SQL> set buf y
SQL> i
  1  select 'y' from dual
  2  .
SQL> l
  1* select 'y' from dual
SQL> set buffer x
SQL> i
  1  select 'x' from dual;
  2  .
SQL> l
  1* select 'x' from dual;
SQL> set buffer y
SQL> l
  1* select 'y' from dual

SQL> set buffer x
SQL> set buffer y
SQL> save n replace
Wrote file n.sql
SQL> r
  1* select * from dual
D
-
X

SQL> set buffer x
SQL> save n replace
Wrote file n.sql
SQL> r
  1* select * from dual
D
-
X

which is a cool trick and allows one to store all their sql script in one file but doesn't really make the script procedural, ie if/then/else, while/do/done, etc One can do this in PLSQL but then then there is no output until the the command is finished.

By: wski

wski — Sat, 31 Dec 2011 18:10:03 +0000

There’s a trick to cheat SQL*Plus into being procedural. See github.com/wski/blackbox

By: AndyP

AndyP — Tue, 29 Nov 2011 20:24:50 +0000

As the script is using ksh then a co-process may be a better option than a named pipe – also has the advantage of not spamming the user/pass in the process list or OS audit records. Although processing of failures with co-processes isn’t trivial. After saying that it wouldn’t address the core issue around encrypted password.

The percieved advantage of wallets is an interesting question – if I have a file with a plain text password in it how much worse is that than having a file where the password is not stored in plain text but I don’t need to be able to decrypt the wallet content to perform a connection (and as we know there must be some level of trust between the Oracle software and the wallet, for an auto-login wallet, there must be a way using a signed(?) Java class to get at the password?

Wallets also pose the question of where the password for the wallet is retained – and how password rotation of the password stored within the wallet is accomplished.

Perhaps pktool is as good an option as an Oracle wallet on a Solaris like OS? The implementation for encrypted zfs filesystems within smf could also be a decent model. An option if the concern is around password stored on backup media would be to use an encrypted zfs filesystem to persist the password in plain-text…..

The opr code is quite clear about what is being gained by the encryption/obfuscation of the password it employs……