One of the most problematic STIG checklist items is this one:
Rule Title: Database account passwords should be stored in encoded or encrypted format whether stored in database objects, external host files, environment variables or any other storage locations.
STIG ID: DG0067-ORACLE11
Rule ID: SV-24641r1_rule
Vuln ID: V-3812
Severity: CAT I
Vulnerability Discussion: Database passwords stored in clear text are vulnerable to unauthorized disclosure. Database passwords should always be encoded or encrypted when stored internally or externally to the DBMS.
Check: Ask the DBA and/or IAO to determine if any DBMS database objects, database configuration files, associated scripts and applications defined within or external to the DBMS that access the database, and DBMS / user environment files/settings contain database passwords.
If any do, confirm that DBMS passwords stored internally or externally to the DBMS are encoded or encrypted.
If any passwords are stored in clear text, this is a Finding.
Fix Text: Develop, document and maintain a list of DBMS database objects, database configuration files, associated scripts and applications defined within or external to the DBMS that access the database, and DBMS / user environment files/settings in the System Security Plan.
Record whether they do or do not contain DBMS passwords.
If passwords are present, ensure they are encoded or encrypted and protected by host system security.
Consider using vendor or 3rd party tools to support external authentication.
This one is a pain because a lot of applications – especially custom Java applications – do not encrypt database credentials stored in their configuration files. So what can we do?
The answer may depend heavily on the specifics of the application framework. A completely custom built application may actually have more options available than one built on a “standard” framework like Grails, which by default limits the ability of the developer to include nifty features like encryption or custom SQL calls.
One option to encrypt passwords is to remove the database credentials from the application configuration altogether. This can be done using Oracle Wallets. The Oracle client will automatically obtain the appropriate database credentials and the application will not have to store or process them at all.
To configure an Oracle Wallet secure password store, complete the following steps:
- On the application server, update the tnsnames.ora file to include an alias specifically for the wallet to use for the database connection:
app_db_alias = (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=dbserver.local)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=dbservice.local)) )
- Update the sqlnet.ora file on the application server to include the following parameters:
SSL_CLIENT_AUTHENTICATION = FALSE SSL_VERSION = 0 SQLNET.WALLET_OVERRIDE = TRUE WALLET_LOCATION = (SOURCE = (METHOD=FILE) (METHOD_DATA=(DIRECTORY=[path to wallet directory])) )
- Create the wallet directory in your preferred location – perhaps in $ORACLE_HOME/network/wallet.
- Create the Oracle wallet from the command prompt, where [wallet location] is the path to the directory where the wallet will be located. Be prepared to provide a password for the wallet. Record the wallet password in a secure location (not unencrypted on the application server) for later reference.
> orapki wallet create –wallet "[wallet location]" -auto_login_local
Note: On some Windows systems, a bug in the Oracle client prevents the wallet from working when constructed with the “-auto_login_local” flag. If you encounter problems, try recreating the wallet with the “-auto_login” flag.
- Populate the wallet with the application’s credentials from the command prompt. Be prepared to provide the wallet’s password again.
> mkstore -wrl "[wallet location]" –createCredential [tnsname] [username] [password]
> mkstore -wrl "[wallet location]" –createCredential app_db_alias app_db_user the_password
- Update the database connection string and/or user credentials in the application configuration. Username and password should now be null, and the database name should be the tnsnames.ora alias created in step 1.The application should now be able to connect to the database using the wallet credentials.
- To confirm that your credentials are now stored in the wallet, use the following command:
> mkstore -wrl "[wallet location]" –listCredential
- To modify the credentials in the wallet after the database password has been changed, use the following command:
> mkstore -wrl "[wallet location]" –modifyCredential [tnsname] [username] [new_password]
- To delete credentials from the wallet, use the following command:
> mkstore -wrl "[wallet location]" –deleteCredential [tnsname]
All quotations from the Database STIG taken from:
Defense Information Systems Agency. Oracle 11 Database Installation STIG Version 8 Release 1.11. http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx. Published April 2014. Accessed September 6, 2014.