DS Logon Password Requirements: Analysis and Solution

Defense Self-Service (DS) Logon provides authentication for DoD services, serving millions of service members, veterans, and dependents. While it’s a critical system, its password requirements present some fascinating challenges from both usability and security perspectives. Let’s analyze what makes these requirements problematic and how we can work within their constraints.

Understanding the Core Issue

The requirement causing the most trouble is deceptively simple: “at least 8 characters must be different” from the current password. A reasonable interpretation of that is eight of the character positions must have different characters. However, the implementation is far stricter than that - the new password must contain eight characters that do not appear at all in the old password.

This creates an interesting mathematical problem. Consider a user with a 128-character password (the maximum length) that uses most available special characters. When they need to change their password, they must find a password with 8 characters that aren’t used in their current password. Since there are 94 characters to choose from in the allowed character set, this becomes more difficult the longer the password. Some probability calculations show that the probability of selecting a 128 character password randomly from a 94 character set with eight or more characters “free” or not included in the final selection is 99.995%. It is almost certain then, that there exists a new password that WILL work, however manually identifying it can prove tedious.

For example, I, being the security minded professional that I am, set a password to 128 characters, the maximum allowed. This was fine, and worked well until I had to reset my password six months later. At that time, using my Bitwarden random password generator, I couldn’t generate a password that had 8 unique characters, at least not quickly as I had to generate the new password, put it into the form, and wait awhile before the website told me I didn’t have 8 different characters. This reddit thread helped me realize I wasn’t crazy.

Security Implications

This requirement has several concerning implications:

Password Storage

The ability to perform character-by-character comparison between old and new passwords suggests potential issues with password storage practices. Secure password storage typically uses one-way hashing, which should make such comparisons impossible. This raises questions about whether passwords might be stored in a way that could be vulnerable to a hacker gaining access to millions of plaintext passwords.

Reduced Entropy

By prohibiting reuse of characters from the previous password, the system reduces the available character set for new passwords. This directly impacts password entropy and thus reduces the theoretical security of the passwords.

Behavioral Impact

These requirements create strong incentives for users to:

• Choose shorter passwords (to preserve characters for future changes)
• Write down passwords (due to increased complexity of memorization)
• Use simpler character sets (to ensure future password changes are possible)

Each of these behaviors runs counter to modern password security best practices.

A Technical Solution

I’ve developed a PowerShell script that helps navigate these requirements while maintaining maximum possible security.

PS C:\> .\New-DSLoginPassword.ps1 -Help
 Generates DS Logon compliant passwords

 PARAMETERS
    -Length <int>
        Length of password (15-128 chars)
        Default: 128

    -ProvideCurrentPassword
        If set, prompts for current password to ensure new password
        meets the '8 different characters' requirement

    -Help
        Shows this help message

 EXAMPLES
    Generate 30-char password:
    .\New-DSLoginPassword.ps1 -Length 30

    Generate password different from current:
    .\New-DSLoginPassword.ps1 -ProvideCurrentPassword

    Show help:
    .\New-DSLoginPassword.ps1 -Help

The script includes several key features:

1. Reserves between 0 and 8 characters to ensure that the next password can be generated, even up to 128 characters
2. Built-in validation testing
3. Copies the new password to the clipboard
4. Secure string handling for password input

Recommendations for Users

While this script provides a workable solution, users should be aware of several best practices:

1. Use a password manager whenever possible
2. Enable multi-factor authentication if available
3. Document your password change dates and maintain awareness of the expiration timeline

Looking Forward

The broader question remains whether such strict password rotation requirements actually improve security. Modern NIST guidelines have moved away from mandatory password rotation, focusing instead on detection of compromised credentials and strong multi-factor authentication.

For those who must use DS Logon, the provided script offers a reliable way to generate compliant passwords. However, this analysis suggests a need for review and modernization of federal authentication systems to align with current security best practices.

Download New-DSLoginPassword.ps1 on Github

Update 12 Feb 2025: Analyzing DS Logon’s Password Storage

In my above analysis of DS Logon’s password requirements, I suggested they might be storing passwords in plaintext to facilitate character-by-character comparison. After further consideration, I realize there could be a secure implementation of these requirements.

A Secure Approach

The system could implement these requirements securely by:

1. When storing a password:
   • Store the normal salted hash of the full password
   • Store a separate salted hash of which characters were used (as a 94-bit bitfield)
   • Keep last 10 password hashes in history
2. When changing password:
   • User provides their current password (required for change)
   • System verifies the new password hash isn’t in the history
   • System compares character usage of provided current password against stored bitfield
   • If verified, stores new password the same way

This approach would meet their requirements while maintaining security best practices. The only “plaintext” comparison happens with the current password that the user actively provides.

NIST Compliance Issues

However, even with a secure implementation, these password requirements still conflict with current NIST standards (NIST 800-63B):

1. Password Expiration
   • DS Logon: Requires password changes every 60 days
   • NIST: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).”
2. Character Composition Rules
   • DS Logon: Requires specific combinations of character types
   • NIST: Recommends against composition rules, stating they provide no real benefit to security and make passwords harder to remember
3. Previous Password Restrictions
   • DS Logon: Must be different from last 10 passwords, with 8 characters different
   • NIST: Only recommends checking against commonly-known compromised passwords
4. Password Complexity
   • DS Logon: Complex rules about character reuse and differences
   • NIST: Emphasizes length over complexity, recommending simple length requirements

While it’s possible to implement DS Logon’s requirements securely, the requirements themselves may be encouraging poor security practices among users. The focus should be on following modern security guidelines that emphasize usability alongside security.