T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:115
- Finding
- Weak XOR Fallback and Unspecified Default Encryption Key## Vulnerability Details **File Location**: `SKILL.md:30-31` and `SKILL.md:115-121` **Vulnerability Type**: Insecure cryptographic design guidance **Risk Level**: Medium ### Vulnerable Documentation Excerpts English rendering of `SKILL.md:30-31`: ```text password | str | Optional custom password. If omitted, a default key is used. ``` English rendering of `SKILL.md:115-121`: ```markdown ## Encryption Strategy The module uses a layered encryption strategy, preferring Fernet and falling back to XOR. | Strategy | Description | |----------|-------------| | **Fernet encryption** (recommended) | AES-128 symmetric encryption with message-integrity verification | | **XOR encryption** (fallback) | Simple XOR encryption with no dependencies, providing basic functionality | | **Code obfuscation protection** | Base64 concealment, dynamic function generation, and namespace cleanup | ``` ### Technical Analysis The Skill documentation promotes encryption of potentially sensitive strings and configuration credentials while allowing two unsafe modes: 1. Encryption may use an unspecified default key when the caller does not provide a password. If this key is static or shared between installations, obtaining it from one copy of the external library could permit decryption of data produced by other users. 2. The cryptographic process may automatically fall back to XOR. Basic XOR encryption does not provide modern confidentiality or integrity guarantees and is vulnerable to known-plaintext analysis, key-reuse attacks, frequency analysis, and ciphertext modification. Automatic fallback from authenticated encryption to a materially weaker algorithm is a fail-open design. Callers may believe that protected data always receives Fernet-equivalent confidentiality and authentication even when the weaker path is active. The project contains only `SKILL.md`; no implementation is included. Consequently, the precise default key, XOR c ...[truncated 2099 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the XOR fallback entirely and fail closed if the authenticated-encryption dependency is unavailable. 2. Remove the implicit default-key mode. Require callers to provide securely generated key material or retrieve it from an approved secret-management system. 3. Use authenticated encryption exclusively, such as Fernet or a carefully implemented AEAD construction. 4. If passwords must be accepted, derive encryption keys with a password-based key derivation function such as Argon2id, scrypt, or PBKDF2 using a unique random salt and an appropriate work factor. 5. Generate unique nonces or initialization vectors according to the selected algorithm and never reuse them where reuse is unsafe. 6. Store algorithm and key-derivation metadata in a versioned ciphertext envelope so decryption does not silently downgrade to a weaker scheme. 7. Return a clear error when secure encryption cannot be performed. Never substitute encoding or obfuscation for encryption. 8. Document key rotation, secret storage, integrity guarantees, and failure behavior. 9. Add tests confirming that missing dependencies, omitted keys, malformed ciphertext, and authentication failures cannot trigger XOR or another weak fallback. 10. Clarify that Base64 encoding and code obfuscation provide no cryptographic confidentiality.