信息安全策略之四：Password Policy

摘要：此为国外某大型企业的信息安全策略规范，涉及企业信息安全的各方面，共数十个策略，我将陆续翻译整理出来。这是第四篇：口令策略。

欢迎转载，但请注明出处及译者。请不要用于商业用途。

原文：

Password Policy

1.0 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 <Company Name>'s entire corporate network. As such, all <Company Name> employees (including contractors and vendors with access to <Company Name> systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their 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 <Company Name> facility, has access to the <Company Name> network, or stores any non-public <Company Name> information.

4.0 Policy
4.1 General
· All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
· All production system-level passwords must be part of the InfoSec administered global password management database.
· All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four 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.
· Passwords must not be inserted into email messages or other forms of electronic communication.
· 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.

4.2 Guidelines
A. General Password Construction Guidelines
Passwords are used for various purposes at <Company Name>. 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:

· The password contains less than eight characters
· The password is a word found in a dictionary (English or foreign)
· The password is a common usage word such as:
o Names of family, pets, friends, co-workers, fantasy characters, etc.
o Computer terms and names, commands, sites, companies, hardware, software.
o The words "<Company Name>", "sanjose", "sanfran" or any derivation.
o Birthdays and other personal information such as addresses and phone numbers.
o Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
o Any of the above spelled backwards.
o Any of the above preceded or followed by a digit (e.g., secret1, 1secret)

Strong passwords have the following characteristics:

· Contain both upper and lower case characters (e.g., a-z, A-Z)
· Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-=/`{}[]:";'<>?,./)
· Are at least eight alphanumeric characters long.
· Are not a word in any language, slang, dialect, jargon, etc.
· Are not based on personal information, names of family, etc.
· 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: "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 <Company Name> accounts as for other non-<Company Name> access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, don't use the same password for various <Company Name> access needs. For example, select one password for the Engineering systems and a separate password for IT systems. Also, select a separate password to be used for an NT account and a UNIX account.

Do not share <Company Name> passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, Confidential <Company Name> information.

Here is a list of "dont's":

· Don't reveal a password over the phone to ANYONE
· Don't reveal a password in an email message
· Don't reveal a password to the boss
· 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 password to co-workers while on vacation

If someone demands a password, refer them to this document or have them call someone in the 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 (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 InfoSec and change all passwords.

Password cracking or guessing may be performed on a periodic or random basis by InfoSec or its delegates. 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.
· 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 <Company 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.0 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

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

7.0 Revision History

译文：

口令策略

1.0 概述
口令是计算机安全的重要方面。它是保护用户账户的第一道门。口令选择不当可能会导致整个企业网络遭到破坏。因此，所有员工（包括承包人和访问企业系统的厂商）都有责任采取如下所述的适当的步骤，选择并保护他们的口令。
2.0 目的
此策略的目的是为了建立一套标准，用来创建强口令，保护口令，并确定口令变更的频率。
3.0 范围
此策略适用于在任何企业系统中拥有账户（或需要口令支持的其它任何访问形式）的所有人员，这些账户可用来访问企业网络或存储非公开的企业信息。
4.0 策略
4.1 通用策略
n 所有系统级口令（例如root、enable、NT admin、应用软件管理员等账户）必须至少每季度更换一次。
n 所有的业务系统级口令必须包含在由信息安全部门管理的统一口令管理数据库中。
n 所有的用户级口令（例如，email、web、桌上计算机等）必须至少每六个月更换一次。推荐的更换间隔是四个月。
n 用户账户如果被赋予系统级权限，不管是通过组成员或“sudo”程序等方式，那么该账户必须拥有一个与该用户其它所有账户都不同的唯一的口令。
n 口令一定不能被放到email消息或其它形式的电子通信消息当中。
n 在使用SNMP协议的地方，共同体字符串必须被定义为缺省的“public”，“private” 和“system”之外的字符，同时也必须不同于登录时使用的口令。如果可用的话，必须使用键入hash功能。
n 所有的用户级和系统级口令必须遵照下列的规程。
4.2 规程
A 通用口令构造规程
在企业中，口令使用有多种目的。一些常见的应用包括：用户级账户、web账户、email账户、屏幕保护、voicemail口令、本地路由器登录等。由于很少有系统支持一次性令牌（即只使用一次的动态口令），因此每个人都应该了解如何选择强口令。
弱口令具有以下特点：
n 口令包含少于8位的字符
n 口令是一个可在字典中查到的单词（英语或其它语言）
n 口令是一个常用词，例如：
u 家庭成员、宠物、朋友、同事等的名字，或漫画人物等。
u 计算机术语、命令、站点、公司、硬件、软件等。
u 企业称谓，如“sanjose”、“sanfran”、或其它派生名称。
u 生日或其它个人信息，如住址、电话号码等。
u 字符或数字有规律的排列，如“aaabbb”、“qwerty”、“zyxwvuts”、“123321”等。
u 上述所有类型的反向拼写。
u 上述所有类型并以数字开头或数字结尾的（如secret1、1secret）。
强口令具有以下特点：
n 既有大写字母，又有小写字母（如a-g，A-G）
n 包含有数字、标点符号、及字母。如0-9，!@#$%^&*()_+|~-=/`{}[]:";'<>?,./)
n 长度至少8位。
n 不是任何一种语言、俚语、方言、行话等的一个单词。
n 与个人信息、家庭成员名字等无关。
n 口令不应在线写下或存储。可以尝试创建一些容易记忆的口令。一种方法是基于一首歌曲名称，标语，或其它短语来创建口令。例如，基于短语“This May Be One Way To Remember”，口令可以为“TmB1w2R!”或“Tmb1W>r~”或其它变形。
注意：不要使用这些示例的口令！

B、口令保护准则
不要在企业账户中使用与其它非企业访问（如，个人ISP账户、option trading、保险单等）相同的口令。如果可能的话，不要对不同的企业系统的访问使用相同的口令。例如，对于工程系统使用一个口令，而对IT系统使用另一个不同的口令。同样的，对于NT账户和UNIX账户也应使用不同的口令。
不要与任何人共享口令，包括行政助理或秘书。所有的口令都应被作为企业的敏感机密信息对待。
以下是“不要做”的列表：
n 不要通过电话将口令泄露给任何人
n 不要在email消息中泄露口令
n 不要将口令泄露给上司
n 不要在他人面前提及口令
n 不要暗示口令的形式（如我的家人名字）
n 不要在调查问卷或安全表格中泄露口令
n 不要与家庭成员共享口令
n 不要在休假时将口令泄露给同事

如果有人需要一个口令，应让他参考此文件或让他与信息安全部门的人员联系。
不要使用应用程序（如Eudora、Outlook、Netscape Messenger）中的记忆口令功能。
而且，不要在办公室的任何地方写下或存放口令。在任何计算机系统（包括掌上电脑）的文件中都不应当不加密的存储口令。
至少每六个月更换一次口令（系统级口令必须至少每季度更换一次）。推荐的口令更换间隔是四个月。
如果怀疑一个账户或口令已被破坏，应向信息安全部门报告，并更换所有口令。
信息安全部门或其代理可能会定期或随机的进行口令的破译和猜解。如果在扫描过程中，一个口令被破译或猜解，则用户需要更换口令。
C、应用程序开发准则
应用程序开发者必须保证他们的程序中包含有下列安全预防措施。应用程序：
n 应当支持个人用户而非组的认证。
n 不应以明文形式或其它易破译的形式存储口令。
n 应当支持某些形式的角色管理，这样一个用户不需要知道他人的口令就可以接管其权限。
n 如果可能的话，应当支持TACACS+ , RADIUS，和/或具备LDAP安全检索的X.509。
D、远程访问用户的口令和口令短语使用
当用户通过远程访问方式访问企业网络时，需要由一次性口令认证或具有强口令短语的公钥/私钥系统进行控制。
E、口令短语
口令短语通常应用在公钥/私钥认证中。公钥/私钥系统定义了公钥与私钥之间的一种数学关系，其中公钥向所有人公开，而私钥仅由用户自己知道。如果没有口令短语将私钥“解锁”，则用户无法获得访问权限。
口令短语与口令不同。口令短语比口令更长，因此也更安全。口令短语通常由多重字符组成，因此能够更有效的抵抗字典攻击。
好的口令短语一方面具有相应的长度，另一方面需要包含大写字母、小写字母、数字和标点符号。一个好的口令短语的示例：“The*?#>*@TrafficOnThe101Was*&#!#ThisMorning”
上述适用于口令的所有规则也适用于口令短语。
5.0 执行
所有违反此策略的员工都会面临纪律处分，直至中止雇佣合同。
6.0 定义
术语 定义
Application Administration Account 用于对应用程序进行管理的所有账户（例如，Oracle数据库管理员、ISSU管理员）。
7.0 修订历史