Hide Notes 

Slide 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;' 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 FROM DBA_USERS 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
Slide 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
Slide 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 PASSWORD_LIFE_TIME 30 PASSWORD_REUSE_TIME 30 PASSWORD_REUSE_MAX 3 PASSWORD_VERIFY_FUNCTION MY_FUNCTION; FUNCTION] --[MEASURED IN NUMBER OF ATTEMPTS] --[MEASURED IN DAYS] --[MEASURED IN DAYS] --[MEASURED IN NUMBER OF REUSES] --[NAME OF PASSWORD VERIFICATION 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