fix(#280): Prevent encryption key exposure via logging
Enhanced logging security in crypto service to prevent potential key material leakage: - Removed error object from logger.error() calls to prevent stack trace leakage - Use generic error messages without sensitive details - Constructor already validates key without exposing it in errors - Added comprehensive tests to verify error messages don't contain key material Security Impact: - Prevents encryption key exposure through error logs - Prevents stack traces that might contain sensitive crypto operation details - All error messages are now generic and safe Test Coverage: - 18 tests covering all encryption/decryption scenarios - Tests verify error messages don't expose key values - Tests cover various invalid key formats (wrong length, non-hex, empty) Files changed: - apps/api/src/federation/crypto.service.ts (logging improvements) - apps/api/src/federation/crypto.service.spec.ts (comprehensive test coverage) Fixes #280 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
45
docs/scratchpads/280-encryption-key-logging.md
Normal file
45
docs/scratchpads/280-encryption-key-logging.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Issue #280: Prevent encryption key exposure via logging
|
||||
|
||||
## Objective
|
||||
|
||||
Ensure encryption key validation errors don't expose the key value in error messages or logs. Prevent complete compromise of federation security.
|
||||
|
||||
## Security Impact
|
||||
|
||||
- Key exposure leads to ability to decrypt all private keys
|
||||
- Complete compromise of federation security
|
||||
- Attacker gains access to all federated communications
|
||||
|
||||
## Location
|
||||
|
||||
`apps/api/src/federation/crypto.service.ts:17-30`
|
||||
|
||||
## Approach
|
||||
|
||||
1. Write tests that verify error messages don't contain key material
|
||||
2. Update validation logic to not include key in error messages
|
||||
3. Ensure structured logging masks sensitive data
|
||||
4. Add tests for various invalid key scenarios
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
- [ ] Write tests for key validation errors (RED)
|
||||
- [ ] Update error messages to remove key exposure (GREEN)
|
||||
- [ ] Verify no key material in logs
|
||||
- [ ] Run quality gates
|
||||
- [ ] Commit and push
|
||||
- [ ] Close issue
|
||||
|
||||
## Testing
|
||||
|
||||
- Invalid key format (wrong length)
|
||||
- Non-hex characters in key
|
||||
- Empty key
|
||||
- Verify error messages are generic
|
||||
- Verify no key material in logs
|
||||
|
||||
## Notes
|
||||
|
||||
- Current error message includes key via template literal
|
||||
- Need to sanitize all error paths
|
||||
- Consider using a constant error message
|
||||
Reference in New Issue
Block a user