T09 · Insecure Skill Coding Practices
- Location
SKILL.md:93- Finding
SMTP Credentials May Be Stored Using Reversible Base64 Encoding
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 93–102
Vulnerability Type: Insecure credential storage
Risk Level: MediumVulnerable Configuration
The following excerpt is translated into English from the reviewed documentation:
markdown ## Credential Management - Credential location: ~/.openclaw/workspace/memory/sc-email-credentials.enc - Encoding method: Base64 or AES encryption - Decoding command example: `base64 -d ~/.openclaw/workspace/memory/sc-email-credentials.enc` ## Related Files - Email list: ~/.openclaw/workspace/memory/enmo-emails.enc - Personal email: ~/.openclaw/workspace/memory/email-credentials.encTechnical Analysis
Base64 is a reversible encoding scheme and provides no confidentiality, integrity protection, access control, or resistance to credential recovery. An
.encfile extension does not make encoded content encrypted. The documented command directly recovers the original content without requiring a cryptographic key.The documentation also discloses predictable paths for dedicated and personal mailbox credential files. If SMTP credentials are stored at these locations using Base64, any local user, process, plugin, or Agent with workspace read access can recover them immediately.
Although AES can provide confidentiality when implemented correctly, the document does not define an authenticated encryption mode, key storage mechanism, file permissions, key rotation policy, or secret-access boundary. The explicit acceptance of either Base64 or AES therefore permits an insecure deployment.
Attack Path
- An attacker obtains read access to the Agent workspace through another compromised Skill, an overly permissive file mode, a shared account, or local process access.
- The attacker uses the predictable paths documented in
SKILL.mdto locate the SMTP credential files. - The attacker executes:
bash base64 -d ~/.openclaw/workspace/mem
...[truncated 1321 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove Base64 as an accepted credential-storage method. Clearly state that encoding is not encryption.
- Store SMTP credentials in an operating-system keychain, managed secret store, or dedicated credential service rather than Agent memory files.
- If file-based storage is unavoidable, use authenticated encryption such as AES-GCM with a randomly generated nonce and a key stored separately in a protected key-management system.
- Restrict secret-file permissions to the minimum required account, such as mode
0600on Unix-like systems, and restrict parent-directory access. - Do not expose personal mailbox credential paths to Skills intended to use only a dedicated mailbox.
- Retrieve credentials only when an explicitly authorized email operation is performed, and avoid placing decrypted credentials in logs, prompts, command-line arguments, or persistent Agent memory.
- Use provider-issued application passwords or narrowly scoped tokens instead of primary mailbox passwords where supported.
- Rotate any credentials that may already have been stored using Base64 and review SMTP logs for unauthorized access.
- Define key rotation, credential revocation, secret-access auditing, and failure-handling procedures.
- Update the documentation so the
.encsuffix is used only for genuinely encrypted and integrity-protected data.