摘自：http://www.itpub.net/thread-1628668-1-1.html
Oracle EBS密碼安全的攻與防
<<攻>>
Oracle EBS密碼安全機制做的並不完善，還有漏洞，已經看到很多的帖子在講如何破解密碼.
最牛的是“Oracle 11i / 12 APPS Password Cracker”這一篇文章（需**）,破解密碼都不用費力的....
http://symplik.blogspot.com/2010/07/oracle-11i-12-apps-password-cracker.html
“How to find out Oracle Apps password??”
http://www.appsdbatraining.com/2011/05/05/how-to-find-out-oracle-apps-password/
“Oracle E-Business Suite Vulnerability: Users Passwords Decrypted”
http://awads.net/wp/2006/12/12/oracle-e-business-suite-vulnerability-users-passwords-decrypted/
“Integrigy Oracle Apps Password Issue”
http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf
還有我之前轉載的一篇
http://blog.csdn.net/pan_tian/article/details/7528932
<<防>>
現在獲取密碼的原理都是基於你已經知道某一個用戶的密碼再來推導apps賬戶或者其他賬戶密碼，所以對DBA來說，一旦安裝完EBS之後，需要立即更改所有預先安裝的fnd_user中所有user的password，尤其是別漏掉guest賬戶的密碼。幾個默認賬戶列表見：http://blog.csdn.net/pan_tian/article/details/7432623
Integrigy_Oracle_Apps_Password_Issue 中講到的保護系統密碼安全的幾點注意事項：
PROTECTING ORACLE APPLICATIONS PASSWORDSThe Oracle Applications encrypted passwords must be protected in order to prevent decryption. The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with the DBA_USERS view.
1. VERIFY APPLSYSPUB DOES NOT HAVE ACCESS TO FND_USER_VIEW [CRITICAL]
Verify APPLSYSPUB and PUBLIC do not have SELECT privileges on the view APPS.FND_USER_VIEW. This is especially an issue with instances that were upgraded from 11.5.6 and prior. FND_USER_VIEW shows all application accounts and the ENCRYPTED_FOUNDATION_PASSWORD. Prior to 11.5.7, APPLSYSPUB may have been granted SELECT privileges on this view to support ADI. This view is not required by APPLSYSPUB, except for old, desupported versions of ADI.
2. CHANGE GUEST ACCOUNT PASSWORD
The password for the GUEST account should be changed from the default of ORACLE or GUEST. 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".
3. CHANGE PASSWORDS FOR ALL SEEDED ORACLE APPLICATIONS ACCOUNTS
Change the passwords for all Oracle Applications 11i seeded accounts (SYSADMIN, WIZARD, APPSMGR, etc.) even though these accounts may be already be 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. 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.
4. CHANGE PASSWORDS FOR ALL DATABASE ACCOUNTS [CRITICAL]
Change the passwords for every database account including all 250+ Oracle Applications schemas. Even though a module is not being used, the database account password must be changed. Use the FNDCPASS utility to change all the database passwords on a periodic basis. In 11.5.10 RUP3, FNDCPASS includes a new option (ALLORACLE) to change all the schema passwords in a single FNDCPASS call (see Metalink Note ID 398942.1).
5. CREATE ALL NEW APPLICATION ACCOUNTS WITH STRONG PASSWORDS
Create all new user accounts with unique and strong passwords. In 11.5.10, User Management (UMX) can be used to securely create new users with strong passwords.
6. SET SERVER SECURITY TO SECURE
Oracle Applications Server Security when set to SECURE requires servers connecting to the Oracle Applications database to provide a secure server ID. This is only used when actually logging into Oracle Applications through a SQL*Net and is not related to database authentication. By setting Server Security to SECURE may prevent an attacker from obtaining the encrypted foundation password under certain circumstances. See the section "AdminAppServer Utility" of the Oracle Applications 11.5.10 System Administrator's Guide – Configuration manual for detailed instructions on setting up Server Security.
7. IMPLEMENT MANAGED SQL*NET ACCESS
11.5.10 introduced a new feature called Managed SQL*Net Access. Managed SQL*Net Access limits the hosts that can connect to the database server using SQL*Net by implementing Oracle TNS Listener valid node checking. Valid node checking is a list of IP addresses that are permitted to connect to the database server. Unfortunately, it is very difficult to implement this feature since a large number of hosts often require access to the database server. See Metalink Note ID 291897.1 for more information on configuring this feature.
8. LIMIT ACCESS TO FND_USER AND FND_ORACLE_USERID
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 ad-hoc query use. These accounts tend to be created with SELECT ANY TABLE system privilege, which allows access to FND_USER. Instead, all non-DBA accounts should be created with a limited set of database privileges for only those tables absolutely required for the business function.
Unfortunately, the FND_USER table is fundamentally required by many reporting and ad-hoc queries, thus it is difficult to directly exclude this table from such database accounts. Also, over 500 standard Oracle Applications views are dependent on FND_USER. A careful review of ad-hoc query privileges should be performed to determine the exact business requirements and privileges required.
Query accounts should not normally require access to FND_ORACLE_USERID, therefore, this table should be easy to exclude from such database accounts.
All user and database passwords should be immediately changed in all cloned databases to prevent decryption of the production passwords.
9. CHANGE ALL APPLICATION ACCOUNT PASSWORDS DURING CLONING [CRITICAL]
As part of the cloning process, change all application account passwords to a random string using a PL/SQL script that calls FND_USER_PKG.CHANGEPASSWORD. An operational issue then exists in that users of the cloned instance will need to obtain the new password. One solution is to use the "Reset Password Functionality" in 11.5.10 and UMX.H. Users needing access will then have to reset their password after each clone of a development or test database. See Metalink Note ID 399766.1 for more information on the UMX Reset Password Functionality.
10.CHANGE THE GUEST ACCOUNT PASSWORD DURING CLONING
The GUEST password requires additional steps in order to change including updating the password in the AutoConfig XML file. As part of the cloning process, follow the steps in Metalink Note ID 396537.1 to change the GUEST password.
11.CHANGE ALL DATABASE ACCOUNT PASSWORDS DURING CLONING [CRITICAL]
All database account password should be changed as part of the cloning process (with the exception of APPLSYSPUB). Even though a module is not being used, the database account password must be changed. In 11.5.10 RUP3, FNDCPASS includes a new option (ALLORACLE) to change all the schema passwords in a single FNDCPASS call (see Metalink Note ID 398942.1). Also, all standard database account passwords (CTXSYS, DBSNMP, etc.) should also be changed as part of each clone.
