Tuesday, October 9, 2012

Secure External Password Store (SEPS) - keeping the password secret from other users on the client OS.

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

    (ADDRESS = (PROTOCOL = TCP)(HOST = ocm.joords.nl)(PORT = 1521)) 

Set up the wallet location in SQLNET.ORA


    (METHOD = file)
       (DIRECTORY = /joords/network)


  • 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.

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


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 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 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select ora_database_name from dual; 


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 - 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