Password Policy

4.1 Password Creation

Passwords should have the following characteristics: 

• The password length must be at least nine characters.  The recommended length is fifteen characters.  When choosing a password, think in terms of choosing a “passphrase”. It is easier to come up with something both memorable and longer when basing your password on a phrase and not just on a word.  For example, “IsItFridayYet2+3” is a 16 character password that is not difficult to memorize.  The terms “password” and “passphrase” should be considered interchangeable as used at Indiana Wesleyan University.
• The password must include characters from at least three of the following four categories: 
  • English uppercase characters (A through Z)
  • English lowercase characters (a through z)
  • Numeric digits (0 through 9)
  • Non-alphabetic characters such as: 

    !@#$%^&*()_+|~-=\`{}[]:";'<>?,./

    (not all systems will accept all punctuation in a password)
• System-level passwords must not be left as their factory defaults, and user-level passwords must not be left as they were when initially assigned by Information Technology.

4.2 Frequency of Change

• l  All user-level passwords must be changed at least every year. The recommended change interval is every six months.
• l  All system-level passwords must be changed at least every year. The recommended change interval is every three months.
• l  User accounts that have any type of system-level access must have a unique password from all other accounts held by that user and must be changed at least every year.  The recommended change interval is every three months.

4.3 Password Protection

• Do not use the same password for Indiana Wesleyan University accounts as for other non-Indiana Wesleyan University access (e.g., personal email, option trading, benefits, etc.).
• Do not share Indiana Wesleyan University user-level passwords with anyone, including administrative assistants or other employees. All passwords are to be treated as sensitive, confidential Indiana Wesleyan University information.
• Don't reveal a user-level password to your supervisor.  Supervisors needing access to an employee’s environment should contact IT for assistance.  (Also, supervisors may request an employee’s access to an account be disabled at any time.)
• Passwords must not be inserted into email messages or other forms of electronic communication unless using encryption approved by Information Security.
• Passwords must never be stored on-line unless using encryption approved by Information Security.
• If a password must be written down to be remembered, it must be protected and concealed and never left in plain view.  If a written password is disposed of, a micro cut shredder or university approved shredding service must be used.
• Don't talk about a password in front of others.
• Don't hint at the format of a password (e.g., "my family name").
• Don't reveal a password on questionnaires or security forms.
• Don't share a password with family members.
• Don't reveal a user-level password to co-workers even when leaving on vacation.

If someone asks you for your password, do not give it out.  Refer them to this document, or have them call the Call Center at extension 2209 and ask for the Information Security department. 

If an account or password is suspected to have been compromised, report the incident to Information Security (call extension 2209) and change the password.

Password cracking may be performed on a periodic or random basis by Information Security or its delegates. If a password is cracked, the user will be required to change it. 

4.4 Application Development & System Administration

This will apply mainly to Information Technology. Application developers must ensure their programs contain the following security precautions. Applications:

• All production system-level passwords must be stored in a secure location for retrieval by approved IT personnel in the event the maintainer of that system and password becomes incapacitated or is unable to carry out their responsibilities for any reason.
• should support authentication of individual users, not groups. 
• should not store passwords in clear text or in any easily reversible form. 
• should provide for some sort of role management, such that one user can take over the functions of another without having to know the other's password. 
• should support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval, wherever possible.