Guidelines for Securing Passwords

Oracle provides guidelines for securing passwords in a variety of situations.

When you create a user account, Oracle AI Database assigns a default password policy for that user. The password policy defines rules for how the password should be created, such as a minimum number of characters, when it expires, and so on. You can strengthen passwords by using password policies.

Follow these guidelines to further strengthen passwords:

**Choose passwords carefully.** In addition to the minimum requirements for creating passwords, follow these additional guidelines when you create or change passwords: - Make the password have a length of between 12 and 1024 bytes, and include both alphabetic characters and digits in the password. - Have the password contain at least one digit, one upper-case character, and one lower-case character. - Use mixed case characters and special characters in the password. - You can include multibyte characters in the password but not in the password of any common user or role. - Use the database character set for the password's characters, which can include the underscore (_), dollar ($), and number sign (#) characters. - You must enclose the following passwords in double-quotation marks: - Passwords containing multibyte characters. - Passwords starting with numbers or special characters and containing alphabetic characters (a--z, A--Z). For example: `"123abc"` `"#abc"` `"123dc$"` - Passwords containing any character other than alphabetic characters, numbers, and special characters. For example: `"abc>"` `"abc@",` `" "` - You do not need to specify the following passwords in double-quotation marks. - Passwords starting with an alphabetic character (a--z, A--Z) and containing numbers (0--9) or special characters ($, #, _). For example: `abc123` `ab23a` `ab$#_` - Passwords containing only numbers - Passwords containing only alphabetic characters (a--z, A--Z) - Do not include double-quotation marks within the password. - Do not use an actual word for the entire password.
To create a longer, more complex password from a shorter, easier to remember password, create the password from the first letters of the words of an easy-to-remember sentence.

For example, “I usually work until 6:00 almost every day of the week” can be Iuwu6aedotw.
Ensure that the password is sufficiently complex.

Oracle AI Database provides a password complexity verification routine, the PL/SQL script utlpwdmg.sql, that you can run to check whether or not passwords are sufficiently complex. Ideally, edit the utlpwdmg.sql script to provide stronger password protections.
Remember that multibyte characters are not allowed in passwords for common users or roles.

For users who are local to a PDB, if you want to use multibyte characters in the password, then ensure that the database character set is configured as a multibyte character set so that the authentication will work properly.

Be aware that because multibyte characters consume more bytes than single-byte characters, they tend to provide less entropy per byte. Because the maximum length of the password is limited to 1024 bytes, to help increase the amount of entropy in a password, Oracle recommends that you also include a number of single-byte characters in the password, even when multibyte characters are being used.
Associate a password complexity function with the user profile or the default profile.

The PASSWORD_VERIFY_FUNCTION clause of the CREATE PROFILE and ALTER PROFILE statements associates a password complexity function with a user profile or the default profile. Password complexity functions ensure that users create strong passwords using guidelines that are specific to your site. Having a password complexity function also requires a user changing their own password (without the ALTER USER system privilege) to provide both the old and new passwords. You can create your own password complexity functions or use the password complexity functions that Oracle AI Database provides.
**Change default user passwords.** Oracle AI Database installs with a set of predefined, default user accounts. Security is most easily broken when a default database user account still has a default password *even after installation*. This is particularly true for the user account `SCOTT`, which is a well known account that may be vulnerable to intruders. In Oracle AI Database, default accounts are installed locked with the passwords expired, but if you have upgraded from a previous release, you may still have accounts that use default passwords. To find user accounts that have default passwords, query the `DBA_USERS_WITH_DEFPWD` data dictionary view.
**Change default passwords of administrative users.** You can use the same or different passwords for the `SYS`, `SYSTEM`, `SYSMAN`, and `DBSNMP` administrative accounts. Oracle recommends that you use different passwords for each. In any Oracle environment (production or test), assign strong, secure, and distinct passwords to these administrative accounts. If you use Database Configuration Assistant to create a new database, then it requires you to enter passwords for the `SYS` and `SYSTEM` accounts, disallowing the default passwords `CHANGE_ON_INSTALL` and `MANAGER`. Similarly, for production environments, do not use default passwords for administrative accounts, including `SYSMAN` and `DBSNMP`.
Enforce password management.

Apply basic password management rules (such as password length, history, complexity, and so forth) to all user passwords. Oracle AI Database has password policies enabled for the default profile. Guideline 1 in this section lists these password policies.

You can find information about user accounts by querying the DBA_USERS view. The PASSWORD column of the DBA_USERS view indicates whether the password is global, external, or null. The DBA_USERS view provides useful information such as the user account status, whether the account is locked, and password versions.

Oracle also recommends, if possible, using Oracle strong authentication with network authentication services (such as Kerberos), token cards, smart cards, or X.509 certificates. These services provide strong authentication of users, and provide protection against unauthorized access to Oracle AI Database.
Do not store user passwords in clear text in Oracle tables.

For better security, do not store passwords in clear text (that is, human readable) in Oracle tables. You can correct this problem by using a secure external password store to encrypt the password within an Oracle wallet. (An Oracle wallet is a secure software container that stores authentication and signing credentials.)

When you create or modify a password for a user account, Oracle AI Database automatically creates a cryptographic hash or digest of the password. If you query the DBA_USERS view to find information about a user account, the data in the PASSWORD column indicates if the user password is global, external, or null. The DBA_USERS view also has a column called ` PASSWORD_VERSIONS, which lists the types of cryptographic hash that exist for the user's password (11G or 12C`).
Disable the HTTP verifier if the user is not going to be using either XDB authentication or HTTP Digest authentication.

The HTTP verifier is used only for XDB authentication and HTTP Digest authentication. If a user is not going to use XDB authentication or HTTP Digest authentication, then you can safely remove the HTTP verifier from the user’s list of verifiers. To remove a user’s HTTP verifier, run the following statement:
```
ALTER USER username DIGEST DISABLE;
```

Related Topics

Securing Authentication for Oracle Database Microsoft Windows Installations

By default, the SQLNET.NO_NTLM parameter setting in the sqlnet.ora file on Microsoft Windows installations with AUTHENTICATION_SERVICES=NTS is TRUE.

If you upgrade from a previous release where the SQLNET.NO_NTLM parameter had not been set, then it defaults to TRUE.

You must include this setting on both the server and client, and this setting should be the same on both. Ideally, you should ensure that SQLNET.NO_NTLM is set to TRUE. However, if there is an authentication failure in extproc, a virtual account, or a local account on Windows, set the client SQLNET.NO_NTLM to FALSE, and then retry the login. If you change SQLNET.NO_NTLM on the server, then you must restart the database.