Approved Date – 02/22/2021
Published Date – 02/22/2021
Reviewed Date – 03/13/2023

1. Purpose

Specify the minimum standards for password creation and to ensure all users manage passwords consistently across their life cycle management used by the District of Columbia Government (“District”) workforce members.

2. Authority

DC Official Code § 1-1401 et seq., provides the Office of the Chief Technology Officer (“OCTO”) with the authority to provide information technology (IT) services, write and enforce IT policies, and secure the network and IT systems for the District. This document can be found at https://code.dccouncil.us/dc/council/code/sections/1-1402.html.

3. Applicability

This policy applies to all District workforce members responsible for application identity and role definition on behalf of the District, and/or any District agency/District/entity who receive enterprise services from OCTO. In addition, this policy applies to any provider and third-party entity with access to District information, systems, networks, and applications.

4. Policy

Each agency must implement a secured password process for all District workforce members with access to the District’s network (hereafter known as users), which must require the following:

4.1 Password Standard for the District

4.1.1. Minimum Password Length

Passwords shall have a minimum of 8 characters with a mix of alphanumeric and special characters; if a system will not support 8-character passwords, then the maximum number of characters allowed by that system shall be used.

4.1.2. Password Composition - link to generate a unique password. Passwords must not consist of the user’s publicly known information (e.g., last name, birthdays, home address, alma mater, pet name, aliases, etc.).

4.1.3. Users shall compose their passwords using the strong password guidelines below:

• Use at least one numeric character (0-8).
• Use at least one uppercase and at least one lowercase alphabetic character (A-Z, a-z).
• Use at least one special character (Example: !, $,*,#,^, or @).

4.2 Password Management for all users

4.2.1. Password Storage

• Passwords shall be memorized and never written down or recorded along with corresponding account information or usernames.
• Passwords must not be saved to unencrypted computer applications such as emails. The use of an encrypted password management application is acceptable (Please contact OCTO for the list of approved password management applications for the District).

4.2.2. Password Reuse

• Users are prohibited from re-using the last 6 previously used passwords.
• Users must take steps to prevent the compromise of his/her password. On the suspicion of a compromise, or in the event of an actual compromise, the user must immediately change his/her password.
• The username and password(s) used for your DC Government accounts must not be used for any other non-DC accounts and services.
• Password Sharing and Transfer
• Passwords must not be transferred or shared with others unless the user obtains appropriate authorization to do so.
• When it is necessary to disseminate passwords in writing, reasonable measures must be taken to protect the password from unauthorized access. For example, after memorizing the password, the user must destroy the written record.
• When communicating a password to an authorized individual orally, take measures to ensure that the password is not overheard by unauthorized individuals.

4.2.4. Electronic Transmission

Passwords shall not be transferred electronically over the Internet using insecure methods. Wherever possible, security protocols including FTPS, HTTPS, IPSEC, etc. shall be used.

4.2.5. Password Expiration and Change after Compromise or Disclosure

• All user accounts that have a strong and complex password (according to our complexity guidelines above) do not need to have an expiration.
• Users are required to change their password when they have a suspected account compromise.
• Agencies are permitted to implement a timeline for password change for their employees as determined based on the level of assessed risk.

4.3. Requirements for System Administrators

4.3.1. Required Passwords for Login

All systems must require that the user authenticates with a valid password before he can log in. All devices with public access, separated from administrative accounts, and with extremely restricted permissions (e.g., web only) are exempted from this requirement.

4.3.2. Systems Default Passwords

System administrators must change default passwords for administrative accounts and deploy multi-factor authentication for user logon.

4.3.3. Password Protection

• System administrators shall harden their systems to prevent password cracking by using technical controls to mitigate “brute force” password attacks.
• All administrators' accounts must be configured to lock out the user after five (5) consecutive failed login attempts.

4.3.4. Logging

Measures shall be put in place to log successful and failed login attempts.

4.3.5. Changing Password after Compromise or Disclosure

System administrators must, promptly, reset system’s password in the event of, or on the suspicion of, a compromise or disclosure.

4.4. Requirements for Application Developers

4.4.1. Require Secure Transmission

Application developers must, whenever required, develop applications that require secure protocols for authentication.

4.4.2. Storing Passwords

Application developers must avoid creating applications that store passwords. If password storage is necessary, the password must not be stored in clear text or in an easily decrypted format (example: salted hash)

4.4.3. Unique User Accounts and Passwords

Applications must support unique user accounts and passwords. Multiple users must not be required to share the same password to use the application.

4.4.4. Single Sign-On (SSO)

Applications must, whenever capable, utilize District approved single sign-on platform for authentication that is based on Active Directory instead of creating another unique ID or username repository.

5. Exemptions

Exceptions to this policy shall be requested in writing to the Agency’s CIO and the request will be escalated to the OCTO Chief Information Security Officer (“CISO”) for approval.

6. Definitions

The definition of the terms used in this document can be found in the Policy Definitions website.