Session Password
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill’s goal is understandable, but its password-guard implementation, recovery-code handling, and billing disclosures are inconsistent enough to require careful review before use.
Treat this as a review-required skill, not a trustworthy session lock. Before installing, verify the exact SkillPay price, avoid running billing code you have not approved, test in a disposable workspace, and do not rely on the password guard until the config-file mismatch and recovery-code exposure are fixed.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
You may think the skill is protecting your OpenClaw session, but the configured password may not be the one the runtime checker actually uses.
The setup script saves credentials to auth-config.json/auth-users.json, while the provided auth-core.js runtime verifier reads memory/passphrase.json and config.passphraseHash. This artifact mismatch makes the advertised session-password protection unreliable.
const CONFIG_FILE = path.join(MEMORY_DIR, 'auth-config.json'); const USERS_FILE = path.join(MEMORY_DIR, 'auth-users.json');
Do not rely on this as an access-control boundary until setup, runtime verification, recovery, and documentation all use the same audited configuration files and an enforced startup/authentication flow.
A recovery code meant to reset the password may be readable by the same local agent or processes the password is supposed to restrict.
If SMTP is not configured, the recovery code is printed, written to a workspace memory file, and returned from the function. For a password-guard skill, exposing reset codes to local files/the agent undermines the recovery boundary.
console.log(`\n您的恢复验证码是: ${code}`); ... fs.writeFileSync(stubFile, `Recovery code for ${email}: ${code}\nExpires in 15 minutes.\n`); ... return { sent: true, method: 'stub', code };Disable stub recovery in production, do not return or write plaintext recovery codes, require a real mail provider or user-approved out-of-band recovery, use cryptographic randomness, and restrict/delete recovery files.
The skill package contains authority to interact with billing and potentially charge SkillPay users, while users cannot easily verify or limit that authority from the metadata.
The billing module embeds a SkillPay API key and includes code to charge a user ID. The registry declares no primary credential, and the artifacts do not show a per-charge approval boundary.
const BILLING_API_KEY = 'sk_20cb...'; ... async function chargeUser(userId, amount = PRICE_PER_CALL) { ... body: JSON.stringify({ user_id: userId, skill_id: SKILL_ID, amount: amount })Move billing authority server-side or into a managed credential flow, remove hardcoded API keys from the package, require explicit user confirmation for charges, and declare billing credentials/capabilities clearly.
You may not know what you will actually be charged for using the skill.
The same artifact states two different per-call prices. Other provided billing/test files also reference different amounts, so the cost disclosure is not coherent.
**Price:** $0.001 USDT per call ... | **Per Call / 按次** | **$0.01 USDT** | Pay per use |
Publish one authoritative price across SKILL.md, package.json, billing.js, tests, and SkillPay, and show the charge amount before any billing action.
Installing the skill may download third-party Node packages, which is normal for this kind of skill but still expands what runs locally.
The user manual instructs npm install, and the package uses caret-version dependencies without a lockfile in the supplied artifacts. Bcrypt is expected for the stated purpose, but the install/provenance details are under-specified.
"bcrypt": "^5.1.1", "axios": "^1.6.0"
Review the package before installation, prefer pinned dependencies with a lockfile, and ensure the registry metadata declares the Node/npm setup requirements.