Oracle Applications 11i User Password Weakness

The inherent weakness of the Oracle Applications 11i user password algorithm is a topic that every so often gets some attention. It bubbles up and then is largely forgotten by most. However, the issue doesn't go away and is very much alive today even in 11.5.10.2. See the references at the end of this post for a little history of the topic. This password weakness (along with the APPLSYSPUB database account) is really a hold-over from client/server and is an inherent design flaw in the current architecture of Oracle Applications.

Many people are missing two critical issues with the Oracle Applications 11i user password encryption -

The encryption is basically two way - (1) if you know any username/password you get the APPS password or (2) if you know the APPS password, you get any user's password. I can see about potential fraud if you know another user's password, but the APPS password is the key to the kingdom. Most likely someone shouldn't have the necessary privileges in production to obtain this information, but often the user's passwords are in cloned instances like development.
Since the decryption routine is a Java class, it is actually easy to create a Java application that calls the decrypt method. Simply put in a username, password, and encrypted password, out comes the APPS password. Put in a username, APPS password, and encrypted password, out comes the user's password. No need to even have access to a database to run the decrypt.

Improving the Oracle Applications 11i password algorithm is a complex change and I don't expect Oracle to fix it in the foreseeable future. Hopefully in Release 12, a strong hash algorithm will be implemented and the APPLSYSPUB database account will no longer exist.

In the meantime, here are a few recommendations to at least improve the security of the user passwords. The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with DBA_USERS.

Verify APPLSYSPUB does not have SELECT privileges on APPS.FND_USER_VIEW. This is especially an issue with instances that were upgraded from 11.5.6 and prior. This view is not required by APPLSYSPUB, except for old versions of ADI.
Change the passwords for all Oracle Applications 11i seeded accounts (SYSADMIN, GUEST, WIZARD, APPSMGR, etc.) even though these accounts may be already disabled. At the same time, make sure all accounts except for SYSADMIN and GUEST are disabled (note a few accounts may be required by a specific module). See Metalink Note ID 189367.1 for the most up to date list of seeded user accounts. Be sure to change the GUEST password and follow the solution in Metalink Note ID 396537.1 for details on changing the password and check that the password was also changed in the System Profile Option "Guest User Password". For years clients have questioned why we recommend always changing the seeded account passwords even though the accounts may be disabled -- this is the reason why.
Create all new user accounts with strong and unique passwords.
Limit access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts including any query-only accounts. Often an APPSREAD or similar database account is created for support purposes or end-user query use. These accounts tend to be created with SELECT ANY TABLE system privilege, which allows them access to FND_USER.

Cloning presents a security issue with Oracle Applications since sensitive information like passwords are in the cloned instance. This applies to both FND_USER as well as DBA_USERS since weak database passwords can be easily cracked (see the tool orabf). The challenge with cloning is that there may be multiple cloned instances with different uses and varying levels of access. Often the development instance is wide-open to all developers and the APPS password is distributed. Support instances may be frequently cloned, contain sensitive information, and be accessed by end-users. Broadly changing passwords all passwords in DBA_USERS and FND_USER usually is difficult to accomplish, but with the security weaknesses of both the application and database passwords changing all the passwords is strongly recommended for every cloned instance.

References about the Oracle Applications 11i Password Weakness

May 2002 - Martin Schlafer and Michael Ackerman of Answerthink were the first ones to really document this issue in their OAUG paper "Oracle Unbreakable? Part I: Ten Hot Security Spots in Oracle Applications 11i" presented at the Spring 2002 OAUG Conference in Toronto. The paper is available for download from the OAUG Conference Paper Archive (OAUG membership required). They highlighted both the password weakness, as well as, the fact that anyone could download all Java JAR files from any Oracle Applications implementation through the web server. The ability to download the JAR file isn't really much of an issue since it is fairly easy to obtain and every Oracle Applications 11i implementation in the world uses the same algorithm. Although, Oracle has limited the downloading from the web server of the core JAR files to just those used by JInitiator.

November 2005 - http://www.erp100.com/viewthread.php?action=printable&tid=1592 (Simplified Chinese -> English Translation) (Sidenote: I would like to know what in Chinese ends up as translating to this - "We know tuberculosis Oracle database provides a common account") This post has sample PL/SQL procedures to crack a password.

May 2006 - http://521102yz.itpub.net/post/5095/84876 (Simplified Chinese -> English Translation) - Report of the above information

December 2006 - http://johanlouwers.blogspot.com/2006/12/oracle-applications-passwords.html