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 ASCL's entire corporate network. As such, all employees, students, consultants, licensees, lessees, franchisees, vendors, customers, agents and affiliates of ASCL are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

This policy establishes best practices for passwords selection as well as protection of use of passwords.

2.0 PURPOSE

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

3.0 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 ASCL facility, has access to the ASCL network, or stores any non-public ASCL information.

4.0 POLICY

4.1 General

1. The allocation and selection of passwords shall be strictly in conformance of this policy. A formal registration and authorization process shall be applied for all new passwords.

2. All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a weekly basis.

3. All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every two months. The recommended change interval is every month.

4. User accounts that have system-level privileges granted through group memberships must have a unique password from all other accounts held by that user.

5. Passwords must not be inserted into email messages or other forms of electronic communication.

6. 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).

7. Management shall conduct a formal review of all user access rights. An escrow of all passwords shall be established for security of all passwords. This escrow shall be protected with access by security administrator and management representative.

8. All user-level and system-level passwords must conform to the guidelines described below.

4.2 Guidelines

1. General Password Construction Guidelines

   Passwords are used for various purposes at ASCL. Some of the more common uses include: user level accounts, web accounts, email accounts, screen saver protection, voicemail 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.

   Poor, weak passwords have the following characteristics:

   1. The password contains less than eight characters

   2. The password is a word found in a dictionary (English or foreign)

   3. The password is a common usage word such as:

      1. Names of family, pets, friends, co-workers, fantasy characters, etc.
         
      2. Computer terms and names, commands, sites, companies, hardware, software.
         
      3. The words "ASCL", "Asian", "Cyber" etc or any derivation.
         
      4. Birthdays and other personal information such as addresses and phone numbers.
         
      5. Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
         
      6. Any of the above spelled backwards.
         
      7. Any of the above preceded or followed by a digit (e.g., cyberlaw1, 1cyberlaw)

   4. Strong passwords have the following characteristics:

      1. Contain both upper and lower case characters (e.g., a-z, A-Z)
         
      2. Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-=\`{}[]:";'<>?,./)
         
      3. Are at least eight characters long.
         
      4. Are not a word in any language, slang, dialect, jargon, etc.
         
      5. Are not based on personal information, names of family, etc.

   5. Passwords should never be written down or stored on-line. 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: "Technology Law is an emerging field of law today" and the password could be: "T_L_is*an_efolt or some other variation.

2. Password Protection Standards

   Do not use the same password for ASCL accounts as for other non-ASCL access (e.g., personal ISP account, trading, etc.). Where possible, don't use the same password for various ASCL access needs. For example, select one password for the Educational resource systems and a separate password for the technology support systems. Also, select a separate password to be used for an NT account and a UNIX account.

   Do not share ASCL passwords with anyone, including ASCL personnel. All passwords are to be treated as sensitive, Confidential ASCL information.

   Here is a list of "dont's":

   1. Don't reveal a password over the phone to ANYONE

   2. Don't reveal a password in an email message

   3. Don't reveal a password to the boss

   4. Don't talk about a password in front of others

   5. Don't hint at the format of a password (e.g., "my family name")

   6. Don't reveal a password on questionnaires or security forms

   7. Don't share a password with family members

   8. Don't reveal a password to co-workers while on vacation

   If someone demands a password, refer them to this document or have them call someone in the ASCL Information Security Department.

   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 without encryption (Refer also to the Acceptable Encryption Policy).

   If an account or password is suspected to have been compromised, report the incident to ASCL Information Security Department and change all passwords.

   Password cracking or guessing may be performed on a periodic or random basis by ASCL Information Security Department or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it.

3. Application Development Standards

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

   1. should support authentication of individual users, not groups.

   2. should not store passwords in clear text or in any easily reversible form.

   3. 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.

   4. should support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval, wherever possible.

4. Use of Passwords and Passphrases for Remote Access Users Access to the ASCL 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.

5. 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 as well as "brute force 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:

   SECurity_IS_NOT_A_PROduct_BUT_A_PROcess*

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

5.0 ENFORCEMENT

Any person bound by this policy who intentionally and/or knowingly violates this policy shall be subject to action deemed fit by the Governing Board of the Asian School of Cyber Laws and shall also be liable to pay adequate and prompt compensation. Such action shall not preclude adequate civil and / or criminal remedy as per the applicable law.

6.0 REVISION HISTORY

This document is created on 12-02-2002 and has been updated last on 22-02-2003. Please note that this document is updated on a regular basis and the latest version can be obtained from: