Oracle Password Repository

I checked this tool today :
http://sourceforge.net/projects/opr

This tool provide a simple way of not hardcoding passwords in shell scripts. Hardcoding passwords in shell scripts is a bad practice. The source code may be shared by many developers, may resides on unsecure servers (CVS), may be printed, etc… The passwords may change often too.

This tool uses a simple file to stores the passwords encrypted. Well, I urge you to secure this file to make it non-accessible for others.

I am not going to decode nor rate the encryption algorythm, the fact is, you do not have clear text passwords. It could be also possible to have clear text password in a separate text file, which would not be that less secure, but it is ugly.

To make it clear (I hope), it is a 2-ways encryption, so if you have access to the file and the source code of the algorythm, you can crack the password. Sounds weak? Well, Oracle Proxy Users with Internet Directory, Application Server, Portal and all those products are not much different. The only 100% passwordless solution I am aware of is the external OS identification.

Well, that said, let’s look how it works.

# ./configure
# make
# make install

let’s create the repository

 
$ export OPRREPOS=$ORACLE_HOME/dbs/oprrepos
$ opr -c

store the password for scott on LSC01

$ opr -a LSC01 SCOTT lsc
please enter the password :
please re-enter the password :
entry (LSC01, scott, lsc) added.

let’s test

$ sqlplus scott/$(opr -r LSC01 SCOTT)@LSC01

SQL*Plus: Release 10.2.0.2.0 - Production on Tue Jul 25 13:51:48 2006

Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options

This is quite convenient. I will use this to store the RMAN password to connect to the RMAN repository in my backup scripts

6 thoughts on “Oracle Password Repository”

  1. Alex Gorbachev

    Yep. Quite convenient. We use password file with restricted access permissions of format:
    user1 pwd1
    user2 pwd2

    and than something like:
    grep “^$ORAUSER” $PWDFILE | awk ‘{print $2}’

    Quite straightforward.

  2. Andreas Piesk

    oracle provides something similar, external password store. oracle documentation to SQLNET.WALLET_OVERRIDE shows how to use it.

    regards

  4. Pingback: Oracle external password store « paperku

  5. Jan-Marten Spit

    i wrote this a long time ago, and deployed it again this year (2013) to save a site from hardcoded passwords. my current requirements are:

    – hardcoded passwords in scripts not running as oracle user, but on the same machine as the db instance.
    – more than a dozen passwords, multiple database instances.

    if there are better (and free/cheap) solutions i would like to know.

    regarding the above article and comments (there is a README in the opr source which is intended to be read)

    – the passwords are NOT stored encrypted, only obfuscated. the security is in the access to the file, not encryption of the stored password.
    – the password file, if you follow the instruction in the README, is only readable for the user who created the repos, eg ‘oracle’. although you can grant access to other OS users.
    – you can easily use a single file for more than one connection (which i never succeeded in doing with oracle wallet, but again, if someone knows..)
    – what is the point in completely hiding passwords from DBA’s who can access anything anyway?
    – i agree that in some situations (only a single user using passwords) , using shell/env is just as convenient

  6. Laurent Schneider Post author

    Hi,

    Not sure what you are looking for. If your requirement is hardcoded password, why would you need a password tool?

    The Oracle wallet is free, and you can use multiple wallets of course (just by changing TNS_ADMIN)… you can not have indeed multiple users as you do use /, which is a limitation obviously.

    – what is the point in completely hiding passwords from DBA’s who can access anything anyway?
    Valid question. One point is traceability. Audit. You could have a policy that each user/admin have its own logging, and only the “application server” is using the technical account. It does not protect you from the DBA. But it protects the DBA from being guilty by default, doesn’t it?

Comments are closed.