7.5 Standards for Passwords
Many children have clubs in which a secret word is used to gain entry to the clubhouse. In my club, the password was hobgoblin . Since no one but our group knew the secret word, we could feel pretty confident that someone saying hobgoblin at our clubhouse door was a member to be allowed in. Operating systems and the Oracle database use passwords in much the same way.
7.5.1 Password Decisions
When you are developing your database security plan, you'll need to make a number of decisions about password use at your site:
Whether a user will be permitted to create and change his own password
How frequently the password will expire and how long a grace period will be allowed before the account is locked
Whether a set standard for password composition is to be used, and what that composition will be
Whether account lockout will be enabled, whether the account can be automatically unlocked, or whether a security manager will have to intervene to unlock a locked account
Whether a password will be permitted to be reused, and what length of time must pass before a password can be reused
How the user or designated account manager will actually change the passwordthrough a created form, through a SQL script, etc.
If users will not be permitted to change their own passwords, the mechanism by which users will be notified of password changes
The decision to enforce a specific pattern for passwords raises the question of just how secure the password will really be since anyone who knows the imposed template will know the form passwords for the system must take. A previous employee could pose a security threat because the username and password structures are known to him or her. If a template for passwords is to be used, we recommend you make the template complex enough to ensure greater difficulty in breaking the password security.
Oracle8 supports a number of new password features, described in Chapter 6. You need to consider all of the following when you set password standards:
- Password aging and expiration
To help ensure that a password will not be compromised, we suggest that passwords be changed on a system at least every three months. The decision of whether to enforce password aging and expiration should be identified in the security plan. The longer a password remains in effect for an account, the greater the possibility that the password can be compromised.
- Password reuse
If a password will be permitted to be reused, we recommend you consider restricting its use to no more frequently than every seventh password cycle. A better approach would to be to completely exclude a password that has been used from being used by that person again.
- Failed login attempts
The number of failed login attempts that will be tolerated on a system should be defined in the security plan. You must also determine the actions that should be taken when the number of failed login attempts has been exceeded.
- Account locking and unlocking
The decision might be made to never enable account locking or never enable automatic account unlocking. Either decision should be documented within the security plan. If account locking is going to be enabled, you need to define the personnel who will be in charge of performing the account unlocking.
7.5.2 Changing Passwords
Since passwords in Oracle8 can now be aged and expired , the decision about whether users should be allowed to change their own passwords becomes a bit more complex. If the user is not going to be permitted to change his or her own password, then the use of password expiration might not make sense in the company's plan. Determining who can change passwords and how often the passwords must be changed becomes vital if the user is not permitted to change passwords. You must also identify in your plan the mechanism by which users will be notified of their password changes. If a large number of users' passwords are going to be changed at the same time, the only feasible way to notify them all quickly might be email. In some sites, the requirement has been to distribute new passwords via regular " snail " mail. Phone calls might be another less secure way to relay password changes when notification must occur very quickly. We do not recommend using telephones to relay password changes, since the person on the other end of the phone may not be the person to whom you think you are talking.
If a user will be permitted to change passwords, you must define the mechanism for changing those passwords. You might want to create a utility that enables the user to change passwordsespecially if direct SQL access is not going to be permitted in the system. Something as elaborate as an Oracle Form or as simple as a SQL statement might be required for a password change. The ability to force the choosing of a password other than one that has already been used is now available (password history), so you will need to specify the length of time that must elapse before a password can be reused.