Password Construction & Protection Guidelines

Password Construction & Protection Guidelines

Picture1

Passwords are a critical component of information security. Passwords serve to protect user accounts; however, a poorly constructed password may result in the compromise of individual systems, data, or our network. This guideline provides best practices for creating secure passwords. The purpose of this guidelines is to provide best practices for the created of strong passwords. This guideline applies to employees, contractors, consultants, temporary and other workers at your company, including all personnel affiliated with third parties. This guideline applies to all passwords including but not limited to user-level accounts, system-level accounts, web accounts, e-mail accounts, screen saver protection, voicemail, and local router logins.

All passwords should meet or exceed the following guidelines

Policy – Password Creation

  • All user-level and system-level passwords must conform to the Password Construction/Protection Guidelines.
  • Users must not use the same password for your company accounts as for other non-company access (for example, personal ISP account, option trading, benefits, and so on).
  • Where possible, users must not use the same password for various company access needs.
  • 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 to access system-level privileges.
  • 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. SNMP community strings must meet password construction guidelines.

Snip20150428_1

Strong passwords have the following characteristics:

  • Contain at least 12 alphanumeric characters.
  • Contain both upper and lower case letters.
  • Contain at least one number (for example, 0-9).
  • Contain at least one special character (for example,!$%^&*()_+|~-=\`{}[]:”;'<>?,/).

Poor, or weak, passwords have the following characteristics:

  • Contain less than eight characters.
  • Can be found in a dictionary, including foreign language, or exist in a language slang, dialect, or jargon.
  • Contain personal information such as birthdates, addresses, phone numbers, or names of family members, pets, friends, and fantasy characters.
  • Contain work-related information such as building names, system commands, sites, companies, hardware, or software.
  • Contain number patterns such as aaabbb, qwerty, zyxwvuts, or 123321.
  • Contain common words spelled backward, or preceded or followed by a number (for example, terces, secret1 or 1secret).
  • Are some version of “Welcome123” “Password123” “Changeme123”

You should never write down a password. Instead, try to create passwords that you can remember easily. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase, “This May Be One Way To Remember” could become the password TmB1w2R! or another variation.

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

Policy – Password Change

  • All system-level passwords (for example, root, enable, NT admin, application administration accounts, and so on) must be changed on at least a quarterly basis.
  • All user-level passwords (for example, email, web, desktop computer, and so on) must be changed at least every six months. The recommended change interval is every four months.
  • The IT Team 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 to be in compliance with the Password Construction Guidelines.

Passphrase

Passphrases generally are 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.

A passphrase is similar to a password in use; however, it is relatively long and constructed of multiple words, which provides greater security against dictionary attacks. Strong passphrases should follow the general password construction guidelines to include upper and lowercase letters, numbers, and special characters (for example, TheTrafficOnThe101Was*&!$ThisMorning!).

Policy – Password Protection

  • Passwords must not be shared with anyone. All passwords are to be treated as sensitive, Confidential <Company Name> information. Corporate Information Security recognizes that legacy applications do not support proxy systems in place. Please refer to the technical reference for additional details.
  • Passwords must not be inserted into email messages, Alliance cases or other forms of electronic communication.
  • Passwords must not be revealed over the phone to anyone.
  • Do not reveal a password on questionnaires or security forms.
  • Do not hint at the format of a password (for example, “my family name”).
  • Do not share <Company Name> passwords with anyone, including administrative assistants, secretaries, managers, co-workers while on vacation, and family members.
  • Do not write passwords down and store them anywhere in your office. Do not store passwords in a file on a computer system or mobile devices (phone, tablet) without encryption.
  • Do not use the “Remember Password” feature of applications (for example, web browsers).
  • Any user suspecting that his/her password may have been compromised must report the incident and change all passwords.

Policy – Application Development

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

  • Applications must support authentication of individual users, not groups.
  • Applications must not store passwords in clear text or in any easily reversible form.
  • Applications must not transmit passwords in clear text over the network.
  • Applications must 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.

Use of Passwords and Passphrase’s

Passphrase 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”

 

 

0 Comments

No Comments Yet!

You can be first to comment this post!

Leave a Reply