The document provides guidelines for enforcing password changes in Oracle databases, detailing methods for both older and newer versions. It discusses the use of SQL scripts to expire passwords for users and the advantages of using resource profiles in Oracle 8.0 and above, including attributes like 'password_life_time' to automate password expiration. Additionally, it outlines various profile attributes for enhancing security, such as limiting login attempts and ensuring password complexity.

1. Forcing Users to Change their Passwords Administration Tips
Forcing Users to change their passwords
It's good general security practice to force Users to change their passwords (although if
you're too vigorous about it, you'll soon discover that Users, unable to remember
constantly changing passwords, start writing them down on scraps of paper -which is a
rather worse security outcome than simply doing nothing in the first place!).
Until Oracle version 8.0, however, there was no automatic way of doing this. The best I
can think of for Oracle 7 is to run the following sort of query:
SET HEAD OFF TERMOUT OFF VERIFY OFF FEEDBACK OFF ECHO OFF PAGESIZE 0
SPOOL CHANGEPWD.SQL
SELECT 'ALTER USER ' || USERNAME || ' PASSWORD EXPIRE;' FROM DBA_USERS
WHERE USERNAME<>'SYS' AND USERNAME <> 'SYSTEM';
SPOOL OFF
/
That will produce a text file output (called, in this case, "changepwd.sql") containing the
following sort of output:
SQL> SELECT 'ALTER USER ' || USERNAME || ' PASSWORD EXPIRE;' FROM DBA_USERS
2 WHERE USERNAME<>'SYS' AND USERNAME <> 'SYSTEM';
ALTER USER DBSNMP PASSWORD EXPIRE;
ALTER USER HOWARD PASSWORD EXPIRE;
ALTER USER OUTLN PASSWORD EXPIRE;
ALTER USER SCOTT PASSWORD EXPIRE;
SQL> SPOOL OFF
You need just to trim out the first few lines containing the actual select statement, and
the last line. Then you are left with a script which can be executed (in this case, it would
be done by typing @changepwd within SQL Plus), and which will have the effect of
expiring the existing password for all Users apart from SYS or SYSTEM.
Note that the fact the password has expired does not mean that Users will automatically
be forced to change their password. All that happens is that the next time they attempt
to log on using their old passwords, they will generate an error condition. The error state
is ORA-28001: the password has expired. Provided your application traps that error and
responds appropriately, they'll be able to change their passwords; otherwise they'll just be
unable to connect. SQL Plus is capable of trapping the error automatically and prompting
for a new password; Server Manager is not.
In Oracle 8.0 and above, things are much easier. The trick is to use resource profiles to
limit the lifetime of passwords, and specifically to use the 'password_life_time' attribute of
profiles.
Every User starts off with a profile called DEFAULT, unless you explicitly assign them a
profile as part of the 'create user...' command, or subsequently assign them one with the
'alter user...' command. A quick way to enforce password limits would therefore be to
issue the following:
ALTER PROFILE DEFAULT LIMIT
Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 3

2. Forcing Users to Change their Passwords Administration Tips
PASSWORD_LIFE_TIME 30;
That means that anyone using the default profile now has their password automatically
expired every 30 days. The change takes place immediately, and there is no need to
switch profiles on with the 'alter system set resource_limit=true' command.
If you want some people to have passwords expire every 30 days, and some after 60 days,
then you'll need to create named profiles to do the deed, and then assign the right profile
to the right Users. For example:
CREATE PROFILE HIGHSECURE LIMIT
PASSWORD_LIFE_TIME 30;
CREATE PROFILE LOWSECURE LIMIT
PASSWORD_LIFE_TIME 60;
ALTER USER FRED PROFILE HIGHSECURE;
ALTER USER MARY LOWSECURE;
Once again, be aware that all the profile does is to expire the password automatically.
That simply puts the User into the ORA-28001 error state, and your application needs to
trap that error and respond appropriately (by prompting for a password change) before the
User can log on again.
Also note that profiles can contain all sorts of other limits for passwords which can help
tighten security.
For example, failed_login_attempts can be used to prevent an unlimited number of
attempts to connect, testing all sorts of possible passwords each time. You either manage
to get it right within the specified number of attempts, or your account is locked out.
Password_reuse_time can be used to stop a user changing a password into itself, by
specifying how many days must elapse between successive uses of the same password.
If you'd rather not have passwords reused at all, then password_reuse_max allows you to
specify a maximum number of times a password can be set as the account password. Set it
to 1, and every password someone uses to connect must be unique.
Finally, there's password_verify_function, which can be set to the name of a function you
write yourself to perform password complexity checks (for example, the password
minimum length, whether it must contains numbers as well as letters and so on). You can
write your own function, and call it anything you like (though the function must be created
in the SYS schema), or you can take a look at the utlpwdmg.sql script in the
ORACLE_HOME/rdbms/admin directory, which is supplied by Oracle and (when run) creates
a sample function for you called "verify_function". The sample script tests that passwords
are at least 4 characters long, contain at least one alphabetic character, one numeric
character, and one special character (such as "$",'%" or "!") -which strikes me as being just
a tad too enthusiastic. It also checks that the password cannot be equal to the username
(a good test to perform, I think), and that the new password must differ from the old one
by at least three characters (which, in my experience, almost guarantees that requests to
change a password fail for no obvious reason, and thus causes Users to start writing their
Copyright © Howard Rogers 2001 10/18/2001 Page 2 of 3

3. Forcing Users to Change their Passwords Administration Tips
passwords down in an attempt to make sure the requisite differences are present... and
passwords which are written down are NOT good passwords!).
I suggest you use the utlpwdmg.sql script as an example of how to do the tests -but then
write your own that makes a bit more sense.
If you utilise all these profile attributes, you might end up with something that looks like
this (I've shown the units of measure for each one, in case there's any confusion):
CREATE PROFILE SECURITY LIMIT
FAILED_LOGIN_ATTEMPTS 3 --[MEASURED IN NUMBER OF ATTEMPTS]
PASSWORD_LIFE_TIME 30 --[MEASURED IN DAYS]
PASSWORD_REUSE_TIME 30 --[MEASURED IN DAYS]
PASSWORD_REUSE_MAX 3 --[MEASURED IN NUMBER OF REUSES]
PASSWORD_VERIFY_FUNCTION MY_FUNCTION; --[NAME OF PASSWORD VERIFICATION
FUNCTION]
This is not a complete listing of all possible password attributes for profiles, but it covers
the most important and useful ones.
Just bear in mind that a User can only have one profile at a time, so if you want to
combine this sort of password-limiting functionality with resource-limiting functionality
(such as restricting the number of sessions a User can have at a time), then both sorts of
profile attribute needs to be set within the one profile.
Copyright © Howard Rogers 2001 10/18/2001 Page 3 of 3