4012.5 - Organization Password

• System administrators and helpdesk will never send requests for password and or user name information without first contacting the end user or the supervising personnel.
• All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months.
• User accounts that have system-level privileges granted through group memberships or programs such as "sudo" must have a unique password from all other accounts held by that user.

• All system-level passwords (e.g., root, enable, Windows Administrator, application administration accounts, etc.) must be changed on at least a quarterly basis.
• All system-level passwords must be part of the InfoSec administered global password management database. (TACACS)
• Where SNMP is used, the community strings must be defined as something other than the standard defaults of "public," "private" and "system" and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2)

All user-level and system-level passwords must conform to the guidelines described below. All users at SBCSS should be aware of how to select strong passwords.

Strong passwords have the following characteristics:

Contain at least three of the five following character classes:

• Lower case characters
• Upper case characters
• Numbers
• Punctuation
• “Special” characters (e.g. @#$%^&*()_+|~-=\`{}[]:";'<>/ etc.)
• Contain at least eight alphanumeric characters

Common examples of weak passwords are:

• Personal Information like names of family, birthdates, pets, friends, co-workers, fantasy characters, etc.
• A word found in a dictionary (English or foreign)
• Computer terms and names, commands, sites, companies, hardware, software
• The words "SBCSS", "password", "secret" or any derivatives
• Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
• Any of the above spelled backwards
• Any of the above preceded or followed by a digit (e.g., secret1, 1secret)
• The original password given when the creation of the account occurred (i.e. the date)

Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: "This May Be One Way To Remember" and the password could be: "TmB1w2R!" or "Tmb1W>r~" or some other variation.

(NOTE: Do not use either of these examples as passwords!)

Passphrases are generally used for public/private key authentication. A public/private key system defines a mathematical relationship between the public key that is known by all, and the private key, that is known only to the user. Without the passphrase to "unlock" the private key, the user cannot gain access.

Passphrases are not the same as passwords. A passphrase is a longer version of a password and is, therefore, more secure. A passphrase is typically composed of multiple words. Because of this, a passphrase is more secure against "dictionary attacks."

A good passphrase is relatively long and contains a combination of upper and lowercase letters and numeric and punctuation characters.

All of the rules above that apply to passwords apply to passphrases.

• Always decline the use of the "Remember Password" feature of applications (e.g., Internet Explorer, Outlook, Mozilla Firefox, Google Chrome).
• Always use different passwords for SBCSS accounts from other non-SBCSS access (e.g., personal ISP account, option trading, benefits, etc.).
• Always use different passwords for various SBCSS access needs whenever possible. For example, select one password for systems that use directory services (i.e. LDAP, Active Directory, etc.) for authentication and another for locally authenticated access.
• Do not share SBCSS passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential SBCSS information.
• Passwords should never be written down or stored on-line without encryption.
• Do not reveal a password in email, chat, or other electronic communication.
• Do not speak about a password in front of others.
• Do not hint at the format of a password (e.g., "my family name").
• Do not reveal a password on questionnaires or security forms or respond to emails or popups soliciting your password or other personal information. (i.e. email saying “We need your password to reset your password, verify who you are, etc.”).
• If someone demands a password, refer them to this document and direct them to the Technology Services Department.
• When given a temporary password by the Helpdesk, immediately change this to your own unique entry.

If a user/account password or a computing device is compromised or suspected of being compromised, the employee MUST immediately notify the Technology Services Department of the incident.

Computers should not be left unattended with the user logged on and no password protected screen saver active. Users should be in the habit of not leaving their computers unlocked. When users leave their computer, the computer can be locked as follows:

For Windows Computers, press the WINDOWS-L keys to lock the computer.

For MAC computers, CONTROL-SHIFT-EJECT keys.

Application developers must ensure their programs contain the following security precautions. Applications:

• Shall support authentication of individual users, not groups.
• Shall not store passwords in clear text or in any easily reversible form.
• Shall 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.
• Shall support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval wherever possible.

Access to the SBCSS Networks via remote access is to be controlled using either a session password authentication or a public/private key system with a strong passphrase.

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Approved: August 14, 2014