Skip Navigation
Weaving a Secure Web Around Education: A Guide to Technology Standards and Security
  Table of Contents and Introductory Material
Chapter 1
  The Role of the World Wide Web in Schools and Education Agencies
Chapter 2
    Web Publishing Guidelines
Chapter 3
    Web-Related Legal Issues and Policies
Chapter 4
    Internal and External Resources for Web Development
Chapter 5
    Procuring Resources
Chapter 6
    Maintaining a Secure Environment
PDF File (1,119 KB)

Ghedam Bairu

(202) 502-7304

Appendix E - 5: Policies and Procedures (Samples): Password Policy

(Rhode Island Department of Education)

1. Overview

Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen password may result in the compromise of [Agency Name]'s entire corporate network. As such, all employees (including contractors and vendors with access to [Agency Name] systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

2. Purpose

The purpose of this policy is to establish a standard for the creation of strong passwords, the protection of those passwords, and the frequency of change.

3. Scope

The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any [Agency Name] facility, has access to the [Agency Name] network, or stores any non-public [Agency Name] information.

4. Policy

4.1 General

  1. All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
  2. All user-level passwords (e.g., e-mail, web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four months.
  3. Each successive password must be unique. Re-use of the same password will not be allowed.
  4. Passwords must be a minimum of eight (8) characters long.
  5. 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.
  6. Passwords must not be inserted into e-mail messages or other forms of electronic communication.
  7. Where Simple Network Management Protocol (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).
  8. All user-level and system-level passwords must conform to the guidelines described below.
  9. Passwords should never be written down or stored online.

4.2 Standards

A. General Password Construction Guidelines

Passwords are used for various purposes at the [Agency Name]. Some of the more common uses include: user-level accounts, web accounts, e-mail accounts, screen saver protection, voice-mail password, and local router logins. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), everyone should be aware of how to select strong passwords.

1.   Poor, unacceptable passwords have the following characteristics:
  Graphic of Checkmark The password contains fewer than eight characters
  Graphic of Checkmark The password is a word found in a dictionary (English or foreign)
  Graphic of Checkmark The password is a common usage word such as:
  • Names of family, pets, friends, co-workers, fantasy characters, etc.
  • Computer terms and names, commands, sites, companies, hardware, software
  • Acronyms for the agency or city.
  • Birthdays and other personal information such as addresses and phone numbers
  • 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)
2. Strong (acceptable) passwords have the following characteristics:
  Graphic of Checkmark Contain both upper and lowercase characters (e.g., a-z, AZ)
  Graphic of Checkmark Have digits and punctuation characters as well as letters (e.g., 0-9, !@#$%^&*()_+|~-=\`{}[]:”;í<>?,./)
  Graphic of Checkmark Are at least eight alphanumeric characters long
  Graphic of Checkmark Are not a word in any language, slang, dialect, jargon, etc.
  Graphic of Checkmark Are not based on personal information, names of family, etc.
  Graphic of Checkmark 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!

B. Password Protection Standards

Do not use the same password for [Agency Name] accounts as for other non [Agency Name] access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, don't use the same password for the various [Agency Name] access needs. For example, select one password for the E-mail systems and a separate password for network systems. Also, select a separate password to be used for an NT account and a UNIX account.

Here is a list of "don'ts":
    Graphic of Checkmark Don’t reveal a password over the phone to ANYONE.
    Graphic of Checkmark Don’t reveal a password in an e-mail message.
   Graphic of Checkmark Don’t talk about a password in front of others.
   Graphic of Checkmark Don’t hint at the format of a password (e.g., “my family name”).
   Graphic of Checkmark Don’t reveal a password on questionnaires or security forms.
   Graphic of Checkmark Don’t share a password with family members.
   Graphic of Checkmark Don’t reveal a password to co-workers while on vacation.
   Graphic of Checkmark Don’t write a password in an obvious place that is accessible to others.

Do not share agency passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential [Agency Name] information.

If someone demands a password, refer them to this document or have them call someone in the Office of Network and Information Systems.

Do not use the "Remember Password" feature of applications (e.g., Eudora, Outlook, Netscape Messenger).

Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on ANY computer system (including Palm Pilots or similar devices) without encryption.

Change passwords at least once every six months (except system-level passwords which must be changed quarterly). The recommended change interval is every four months.

If an account or password is suspected to have been compromised, report the incident to the Office of Network and information Systems and change all passwords.

The Office of Network and Information Systems or its delegates may perform password cracking or guessing on a periodic or random basis. If a password is guessed or cracked during one of these scans, the user will be required to change it.

C. Application Development Standards

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

  • 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, and
  • should support TACACS+, RADIUS, and/or X.509 with LDAP security retrieval, wherever possible.

D. Use of Passwords and Passphrases for Remote Access Users

Access to the [Agency Name] networks via remote access is to be controlled using either a one-time password authentication or a public/private key system with a strong passphrase.

E. Passphrases

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. An example of a good passphrase:

"The*?#> *@TrafficOnThe101Was*&#!#ThisMorning."

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

5. Enforcement

Any employee found to have violated this policy may be subject to disciplinary action and loss of network privileges.

6. Definitions


Application Administration Account: Any account that is for the administration of an application (e.g., Oracle database administrator, ISSU administrator).