T09 · Insecure Skill Coding Practices
- Location
SKILL.md:75- Finding
Persistent Collection and Plaintext Storage of User Credentials
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:75-86,SKILL.md:94-103,SKILL.md:133-170;data/accounts.json:2
Vulnerability Type: Plaintext credential collection, persistence, and reuse
Risk Level: HighVulnerable Configuration Snippets
The following is an English rendering of the credential-storage directives in
SKILL.md:75-86:text Credentials supplied by users must be remembered persistently: Once a user sends a registered account and password, I must immediately save them persistently. They must not be kept only in the conversation. Storage location: data/accounts.json Format: { "username": { "username": "value", "password": "value", "school": "school name" } } Before every post or submission, read this file. If credentials exist, automatically log in with them.The authenticated school lookup in
SKILL.md:94-103transmits the reusable password directly:json { "username": "username", "password": "password" }The registration workflow in
SKILL.md:133-170also instructs the agent to collect and retain sensitive registration data:text Ask the user for the desired username, email address, and password. Call the registration endpoint with the school, region, username, email address, and password. After successful registration, write the account information to data/accounts.json for persistent storage.The account database description at
data/accounts.json:2confirms that plaintext credentials are intended to be written to the project workspace:json { "_description": "Forum user account database. After a user gives the agent a registered account and password, the agent must immediately write them to this file for persistent storage, keyed by username. Before posting or submitting, read this file to determine whether the user is registered.", "accounts": {} }Technical Analysis
The skill explicitly requires users to disclose reusable forum passwords through th ...[truncated 3291 chars]
- Remediation
View remediation
Remediation Suggestions
-
Stop requesting passwords in conversation
- Remove all instructions requiring users to send passwords to the agent.
- Direct users to the first-party HTTPS registration and login interface.
- Warn users not to disclose passwords, recovery codes, or session cookies to the agent.
-
Replace passwords with delegated authorization
- Implement OAuth, a device authorization flow, or another first-party authorization mechanism.
- Issue narrowly scoped tokens for required actions such as creating posts.
- Ensure tokens are revocable, time-limited, audience-restricted, and bound to the minimum required permissions.
-
Do not store authentication secrets in project files
- Remove the password field from
data/accounts.json. - Store only non-sensitive identifiers needed to associate a user with a school or forum account.
- If a delegated token must be retained, use an operating-system secret manager or managed vault rather than a JSON file.
- Remove the password field from
-
Protect any unavoidable tokens
- Encrypt secrets at rest using keys stored separately from the project.
- Enforce restrictive filesystem permissions and per-user isolation.
- Prevent secrets from entering logs, prompts, error messages, backups, telemetry, and memory summaries.
- Implement expiration, rotation, revocation, and deletion controls.
-
Minimize registration data handling
- Perform password entry only on the first-party registration site.
- Do not proxy registration passwords through the agent.
- Retain school affiliation and email data only where necessary and with clear disclosure.
-
Correct privacy claims
- Distinguish between anonymous public display and internal identity collection.
- Clearly document what data is collected, where it is stored, why it is needed, how long it is retained, and how users can delete it.
-
Remove previously stored credentials safely
- Search existing deployments, logs, hi ...[truncated 248 chars]
-