Passwords, Authentication and Account Locking

Start by changing all passwords for accounts created during the database build process, including the password for the DBSNMP user. Also change all passwords created by third party applications, such as SAP or WebSphere. Pete Finnigan has compiled a list of 600 users and their default passwords, which is avavailable on his Web site. All of the other security measures won't achieve much if an attacker can simply log in to your database. Once an attacker has logged into the database, they can begin a privilege escalation attack, unless of course they have logged in as system/manager or sys/change_on_install.

Pete also offers a password auditing tool from his site, http://www.petefinnigan.com. Oracle also released a password checking utility with the January 2006 CPU, called the Oracle Default Password Scanner. Even if you aren't installing the CPUs (you really should!) you can download a copy from the Scanner FAQ on Metalink. Download one of these tools right away, and use it to check the accounts in your database.
Link to Scanner FAQ

When changinge passwords, use the PASSWORD command, rather than ALTER USER. The PASSWORD command encrypts the password, while ALTER USER transmits the information in clear text.

Example:
SQL> password dbsnmp

Use impossible passwords or lock any user that doesn't need to be logged in, such as a schema owner in a production database. An impossible password is created by using ALTER USER IDENTIFIED BY VALUE, where the value is not a 16 digit hexadecimal number.

Example:
SQL> alter user sys identified by value 'IMPOSSIBLE';

Because the value IMPOSSIBLE cannot be decrypted to a usable password, the account can not be logged in. A simpler way to disable logins is to lock the account. This is particularly useful for schema owners that may need to be logged in occasionally for updates.

Example:
SQL> alter user sys account lock;

Lock the SYS account, and connect "/ as sysdba" using the dba group membership of the operating system account. Locking the user prevents an outsider from "guessing" the SYS password, but still permits the DBA to connect after properly authenticating on the database server.

While external authentication may be useful in limited cases (you don't want users to have accounts on the database server), do not allow remote os authentication. The remote_os_authent parameter is set to false by default, and this is one case where the default is the most secure setting.

User passwords are not case sensitive, which makes them easier to crack. Password cracking tools are available on the Internet, and can be used from a remote server. You can reduce the risk or a successful brute force attack by locking the account after multiple failed login attempts, and auditing failed login attempts. Password expiration, password reuse, and failed login attempts can be implemented by defining them in the user profile. Password length and strength can be managed by creating a function, and associating it with the profile.
More about profiles.
More about auditing.