T09 · Insecure Skill Coding Practices
- Location
SKILL.md:121- Finding
Technical Specification Permits Plaintext Password Storage
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 121
Vulnerability Type: Plaintext storage of authentication credentials
Risk Level: HighRelevant excerpt translated into English:
markdown - Core process: Include registration and login. Because this is only a demo, minimize complexity by asking whether the user accepts storing passwords in plaintext. If the user confirms, explicitly include this in the technical document. User permission is mandatory.Technical Analysis
The Skill explicitly allows a downstream coding agent to implement plaintext password storage when the user consents. Consent does not mitigate the underlying security flaw: authentication secrets remain directly recoverable from the database, backups, logs, exports, or development artifacts.
Passwords must be processed with a password-specific, adaptive one-way hashing algorithm and a unique salt. Encryption alone is not an adequate substitute because compromise of the decryption key would expose every password. Describing the application as a demo also does not make plaintext storage safe, particularly because users may reuse real credentials or later deploy the demo publicly through the supported Vercel and Neon workflow.
Attack Path
- The Agent asks a nontechnical user whether plaintext password storage is acceptable.
- The user approves it without fully understanding the security consequences.
- The Agent adds plaintext storage as a requirement in the technical specification.
- A downstream coding AI implements registration and login by saving raw passwords in SQLite or Neon.
- The application or database is deployed, copied, backed up, exposed through a vulnerability, or accidentally published.
- An attacker reads the password column directly, without needing to crack password hashes.
- The attacker uses the recovered credentials against the demo and potentially against unrelated services where ...[truncated 558 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the option to store passwords in plaintext, regardless of user approval or demo status.
- Require a maintained password-hashing implementation based on Argon2id, bcrypt, or scrypt, with unique salts and appropriate work factors.
- Prefer passwordless authentication or fixed, clearly labeled non-secret demo identities when authentication security is outside the demo scope.
- Warn users never to reuse real passwords in demonstration applications.
- Ensure passwords are excluded from logs, error messages, analytics, fixtures, repository content, and database exports.
- Add a technical-document requirement for secure session handling, generic authentication errors, and rate limiting where login is exposed publicly.
- If existing plaintext credentials may already have been stored, invalidate them, remove the plaintext values, and require password resets rather than attempting to migrate the exposed credentials silently.