One of the problem is hard coded oracle passwords in batch scripts executed by schedulers. Often used is using function to get a password from a file located on the system. This file could be encrypted or plain text. With this function it is possible to hide the password in script and on OS platform. Do you know

Secure External Password Store

(SEPS), what is it. With SEPS introduced since Oracle 10g you can store password credentials for connecting to databases by using a client-side Oracle wallet. An Oracle wallet is a secure software container that stores authentication and signing credentials. This wallet usage can simplify large-scale deployments that rely on password credentials for connecting to databases. When this feature is configured, application code, batch jobs, and scripts no longer need embedded user names and passwords. This reduces risk because the passwords are no longer exposed, and password management policies are more easily enforced without changing application code whenever user names or passwords change. This method of SEPS works on every OS platform. SEPS is part of the Oracle walet stack, a security option on license and for a lot of people not usable. SEPS is free, this feature does not require the Oracle Advanced Security Option. If nothing is used of the wallet functionality and only the Secure External Password Store (SEPS) part is used than it is free an option on EE.

Lets play - Configuring Clients to Use the Secure External Password Store

The connection is done by:

[CONNECT|SQPLUS|RMAN] /@db_connect_string
[CONNECT|SQLPLUS] /@db_connect_string AS SYSDBA
[CONNECT|SQPLUS] /@db_connect_string AS SYSOPER

Create an entry in the TNSNAMES.ORA

JOORDS_BATCH = 
  (DESCRIPTION = 
    (ADDRESS = (PROTOCOL = TCP)(HOST = ocm.joords.nl)(PORT = 1521)) 
    (CONNECT_DATA = (SERVICE_NAME = PROD1)) 
  )

Set up the wallet location in SQLNET.ORA

SQLNET.ALLOWED_LOGON_VERSION = 11

WALLET_LOCATION =
  (SOURCE =
    (METHOD = file)
    (METHOD_DATA =
       (DIRECTORY = /joords/network)
       ))

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE

SQLNET.WALLET_OVERRIDE = TRUE setting cause all "CONNECT /@db_connect_string" statements to use the information in the wallet at the specified location to authenticate to databases.

SQLNET.ALLOWED_LOGON_VERSION = To set the minimum authentication protocol allowed when connecting to Oracle Database instances.
See SQLNET.ALLOWED_LOGON_VERSION

Note:

If an application uses SSL for encryption, then the sqlnet.ora parameter, SQLNET.AUTHENTICATION_SERVICES, specifies SSL and an SSL wallet is created. If this application wants to use secret store credentials to authenticate to databases (instead of the SSL certificate), then those credentials must be stored in the SSL wallet. After SSL authentication, if SQLNET.WALLET_OVERRIDE = TRUE, then the user names and passwords from the wallet are used to authenticate to databases. If SQLNET.WALLET_OVERRIDE = FALSE, then the SSL certificate is used.

Create a Wallet

pwd /joords/network echo $TNS_ADMIN /joords/network mkstore –wrl . –create Enter password: Enter password again: (using a "." in the syntax to specify current working directory) ls -trl lrwxrwxrwx 1 oracle oracle 74 Oct 9 03:21 tnsnames.ora -> /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora -rw-rw-r-- 1 oracle oracle 208 Oct 9 04:47 sqlnet.ora -rw------- 1 oracle oracle 3512 Oct 9 04:50 ewallet.p12 -rw------- 1 oracle oracle 3589 Oct 9 04:50 cwallet.sso

Creating the Credentials for SEPS

mkstore –wrl . -createCredential joords_batch scott tiger Enter password: Create credential oracle.security.client.connect_string1

Testing the Wallet Credential

sqlplus /@JOORDS_BATCH SQL*Plus: Release 11.2.0.1.0 Production on Tue Oct 9 04:56:40 2012 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select ora_database_name from dual; ORA_DATABASE_NAME -------------------------- PROD1.ORACLE.COM SQL> exit

Is this a secure solution "no it is not"
The security of the Oracle Wallet is only file-based, so if an attacker can still read the wallet they can login as that user from a different machine by copying over the contents of the Wallet without having to supply the password. Thus the security of the Wallet for invoking scripts remotely is not that much better than the original plaintext password stored in the shell script invoking SQL*PLUS, because BOTH METHODS DEPEND ON OS FILE AND DIRECTORY PERMISSIONS FOR THEIR SECURITY! Wallets can be copied to different machines, which can represent a security risk. In 11g Release 2, you can prevent the auto login functionality of the wallet from working if it is copied to another machine by creating a local wallet using the "orapki" command, instead of the "mkstore" command.

orapki wallet create -wallet "/joords/network" -pwd "mypassword" -auto_login_local

Once the wallet is created, it can be modified using the "mkstore" command described below. Add the password credentials to the wallet using the -createCredential option.

mkstore -wrl "/joords/network" -createCredential joords_batch scott tiger Enter password: Create credential oracle.security.client.connect_string1

Validate the current passwords

mkstore -wrl . -listCredential Oracle Secret Store Tool : Version 11.2.0.1.0 - Production Copyright (c) 2004, 2009, Oracle and/or its affiliates. All rights reserved. Enter wallet password: List credential (index: connect_string username) 1: joords_batch scott

Password credentials of existing wallet entries can be modified or deleted using the following commands.

mkstore -wrl <wallet_location> -modifyCredential mkstore -wrl <wallet_location> -deleteCredential

MOS references:

340559.1 – Using The Secure External Password Store

1123423.1 – How To Use an External Password Store with JDBC/Thin

403744.1 - How to Use an External Password Store with the OCI JDBC Driver

Joords Oracle DBA blog

Pages

Tuesday, October 9, 2012