T09 · Insecure Skill Coding Practices
- Location
SKILL.md:19- Finding
Plaintext Decryption Key Stored at a Predictable File Path
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 19-21
Vulnerability Type: Plaintext sensitive-data storage
Risk Level: MediumVulnerable Documentation Excerpt
The following is an English translation of the complete relevant source excerpt:
markdown - The encrypted `MEMORY.md` is unreadable and must be decrypted with the key. - The key is stored in a separate file: `~/.openclaw/.memory-key`. - The key itself is not encrypted; an additional backup is recommended.Related instructions at lines 47 and 74-78 also tell the user to back up the key, including to secure cloud storage, without specifying key wrapping, access-control requirements, or secure storage mechanisms.
Technical Analysis
The documented design stores the memory-decryption key in plaintext at the predictable path
~/.openclaw/.memory-key. The Skill does not require restrictive file permissions, ownership validation, atomic file creation, an operating-system credential store, hardware-backed key protection, or encryption of exported key backups.Encryption only protects memory while its key remains confidential. A process, malicious Skill, compromised user account, or incorrectly privileged local user that can read this file can obtain the key and decrypt both
MEMORY.mdand encrypted backups. Recommending a cloud backup of the unwrapped key creates an additional exposure point if that account or storage location is compromised.Because the project contains only
SKILL.mdand no implementation, actual file permissions and cryptographic behavior cannot be verified. This finding concerns the explicitly documented insecure key-storage design rather than a confirmed executable implementation flaw.Attack Path
- The user enables memory encryption, causing the documented design to generate
~/.openclaw/.memory-key. - An attacker gains read access through a malicious local process, another Skill operating under the s ...[truncated 1008 chars]
- The user enables memory encryption, causing the documented design to generate
- Remediation
View remediation
Remediation Suggestions
- Store the key in an operating-system credential manager, such as Keychain, Credential Manager, or Secret Service, rather than in a plaintext file.
- Prefer hardware-backed key storage where available and prevent extraction of the raw key.
- If file-based storage is unavoidable:
- Create the file atomically with owner-only permissions such as
0600. - Ensure its parent directory is accessible only by the owner.
- Verify ownership, permissions, file type, and absence of symbolic links before every use.
- Reject operation if the key is readable by a group or other users.
- Create the file atomically with owner-only permissions such as
- Protect exported recovery keys with authenticated encryption under a separate passphrase-derived key. Use a modern password-based derivation function such as Argon2id or scrypt with a unique salt and appropriate resource parameters.
- Do not recommend uploading an unwrapped key to cloud storage. Document an approved encrypted export and recovery process instead.
- Use authenticated encryption, such as AES-256-GCM, to provide confidentiality and integrity for memory and backup files.
- Add key rotation and re-encryption procedures so exposure of one key does not indefinitely compromise all future backups.
- Document revocation, recovery, backup separation, and secure deletion requirements.
- Add implementation and automated tests that verify permissions, ownership checks, authenticated decryption, backup handling, and failure behavior.
