Enhance Password Memory Security - Use char[] Instead of String

[devondragon]

Overview

Passwords are currently handled as String objects throughout the application, which poses a security risk as String objects are immutable and remain in memory until garbage collected. This issue tracks the implementation of secure password handling using char[] arrays that can be explicitly cleared from memory.

Problem Statement

• Password strings remain in memory after use, potentially accessible via memory dumps
• String objects cannot be explicitly cleared from memory
• Password data may persist in memory longer than necessary, increasing exposure risk

Proposed Solution

Replace String usage with char[] for password handling in critical paths and implement secure cleanup practices.

Implementation Plan

Phase 1: Create Security Utilities

• Create PasswordSecurityUtil class with secure comparison and clearing methods
• Implement constant-time password comparison to prevent timing attacks
• Add utility methods for safe char[] to String conversion when required

Phase 2: Update DTOs

• Modify UserDto and PasswordDto to use char[] for password fields
• Add clearPassword() methods to explicitly clear sensitive data
• Maintain backward compatibility with overloaded methods

Phase 3: Update Services

• Update PasswordPolicyService.validate() to accept char[] parameters
• Modify UserService.changeUserPassword() to use char[] internally
• Add overloaded methods for backward compatibility during transition

Phase 4: Update Controllers

• Modify UserAPI endpoints to handle char[] passwords
• Add finally blocks to ensure password data is cleared after operations
• Update request/response handling to minimize password exposure

Affected Files

• com.digitalsanctuary.spring.user.dto.UserDto
• com.digitalsanctuary.spring.user.dto.PasswordDto
• com.digitalsanctuary.spring.user.service.PasswordPolicyService
• com.digitalsanctuary.spring.user.service.UserService
• com.digitalsanctuary.spring.user.api.UserAPI

Technical Considerations

1. Library Limitations: Some libraries (Passay, Spring Security PasswordEncoder) require String inputs. Minimize conversion points and clear data immediately after use.

2. Backward Compatibility: Maintain overloaded methods during transition period to avoid breaking changes.

3. Performance Impact: Monitor performance impact of char[] conversions and optimize critical paths as needed.

Security Benefits

• Reduced password exposure time in memory
• Ability to explicitly clear sensitive data
• Protection against memory dump attacks
• Improved compliance with security best practices

Testing Requirements

• Unit tests for all char[] handling methods
• Integration tests for complete authentication flows
• Security tests to verify memory clearing functionality
• Performance tests to measure impact of conversions

Success Criteria

• All password entry points use char[] arrays
• Sensitive data cleared within 100ms of use
• No functional regression in existing tests
• Security scans show reduced password exposure in memory

References

• OWASP Secure Coding Practices
• CWE-316: Cleartext Storage of Sensitive Information in Memory
• Related PR: Add Password Policy Functionality #217 (Password Policy Implementation)

Priority

Medium - Security enhancement that improves defense-in-depth but not a critical vulnerability

Labels

• enhancement
• security
• technical-debt

[create-issue-branch]

Branch issue-218-Enhance-Password-Memory-Security---Use-char-Instead-of-String created!

[devondragon]

After comprehensive code review and architectural analysis, I've decided not to
merge this PR. The core issue is that in a Spring/Jackson environment, password String objects are created by the framework during JSON
deserialization and Bean Validation before our code ever executes, meaning passwords exist as String objects for 85-95% of their lifecycle regardless
of the char[] implementation. The char[] approach only reduces exposure during a small window after conversion, while adding significant complexity
through dual state management (maintaining both String and char[] fields) and introducing critical bugs - specifically, the getPasswordChars()
methods create new uncleaned char[] arrays on each call that are never tracked or cleared, defeating the security purpose. Additionally, the
controller code still calls the old String-based methods rather than the new char[] methods, so the secure code paths are never actually executed.
The complexity-to-benefit ratio doesn't justify merging this change. I recommend we focus on simpler, more effective security measures like
infrastructure-level protections, faster password processing to minimize exposure time, and considering modern authentication alternatives that reduce
our dependency on password handling altogether.