vanara 0.1.0 → 0.2.0

package/catalog/skills/secure-auth/examples/auth-flow.md

@@ -0,0 +1,60 @@
+# Annotated Auth Flows
+
+Three end-to-end flows with the security-relevant step called out at each line. These are reference
+sequences, not framework-specific code.
+
+## 1. Password login → session
+
+```text
+POST /login  { email, password }
+  1. Look up user by email.
+  2. ALWAYS run argon2.verify even if the user doesn't exist (compare against a dummy hash)
+     -> keeps response time uniform, defeats account enumeration by timing.
+  3. On success:
+       a. Regenerate the session ID            <- defeats session fixation
+       b. Persist session server-side (user, absolute + idle expiry, CSRF token)
+       c. Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
+  4. On failure: generic 401 "invalid email or password" (never say which was wrong).
+  5. Increment a per-account + per-IP failure counter -> backoff/lockout on abuse.
+```
+
+The dummy-hash compare in step 2 matters: skipping the hash when the user is missing makes "no such
+user" measurably faster than "wrong password," which is an enumeration oracle.
+
+## 2. Access token refresh (JWT model)
+
+```text
+Login issues:
+   access_token  (JWT, exp ~10 min, carried in Authorization: Bearer)
+   refresh_token (opaque, stored server-side, exp ~14 days, in HttpOnly cookie)
+
+POST /token/refresh   (presents refresh_token)
+  1. Look up the refresh token record server-side.
+  2. If it's already been used (rotated out) -> REUSE DETECTED:
+        revoke the entire token family + force re-login.       <- catches stolen refresh tokens
+  3. Otherwise: issue a NEW access_token AND a NEW refresh_token,
+     invalidate the old refresh token (rotation).
+  4. Logout: delete the refresh record -> access dies within ~10 min.
+```
+
+## 3. OAuth2 / OIDC login (Authorization Code + PKCE)
+
+```text
+  1. App generates code_verifier (random) + code_challenge = SHA256(verifier),
+     and a random `state`. Store both in the user's pending session.
+  2. Redirect to provider /authorize?...&code_challenge=...&state=...&scope=openid email
+  3. User authenticates at the provider; redirected back with ?code=...&state=...
+  4. App verifies returned state == stored state.               <- CSRF defense on callback
+  5. App POSTs code + code_verifier to /token.                  <- PKCE binds code to this client
+  6. Provider returns access_token + id_token (+ refresh_token).
+  7. App verifies id_token: signature (JWKS), iss, aud, exp, nonce.  (see jwt-verify.ts)
+  8. App maps id_token.sub -> local user (create on first login). Use `sub`, not `email`.
+  9. Establish a local session/token exactly as in flows 1 or 2.
+```
+
+## Logout that actually logs out
+
+- Server-side sessions: delete the session record (not just the cookie). Optionally support
+  "log out all devices" by deleting every session for the user.
+- JWT model: delete the refresh token; rely on short access-token expiry for the residual window. If you
+  need *instant* access-token revocation, keep a short-TTL denylist of token IDs (`jti`).

package/catalog/skills/secure-auth/examples/jwt-verify.ts

@@ -0,0 +1,89 @@
+// jwt-verify.ts
+//
+// A dependency-light illustration of how to verify a JWT *correctly*. In production
+// you would use a maintained library (e.g. `jose`) plus JWKS fetching/caching — this
+// file shows the checks that library performs so you know what "good" looks like and
+// can audit a hand-rolled verifier. It uses only the Node built-in `crypto` module.
+//
+// SECURITY NOTES (the parts people get wrong):
+//   1. PIN the algorithm. Never trust the token's own `alg` header — an attacker can
+//      set `alg: none` or switch RS256 -> HS256 and sign with the public key.
+//   2. ALWAYS verify the signature BEFORE reading any claim as trusted.
+//   3. Check `iss`, `aud`, and `exp` (and `nbf`/`iat`) — a valid signature on a token
+//      meant for a different audience is still not for you.
+
+import { createHmac, timingSafeEqual } from 'node:crypto';
+
+interface VerifyOptions {
+  secret: string;          // HMAC secret (HS256). For RS256 you'd verify with a public key.
+  issuer: string;          // expected `iss`
+  audience: string;        // expected `aud`
+  now?: number;            // injectable clock (seconds) for testing
+}
+
+interface JwtClaims {
+  iss?: string;
+  aud?: string | string[];
+  exp?: number;
+  nbf?: number;
+  sub?: string;
+  [k: string]: unknown;
+}
+
+function b64urlDecode(part: string): Buffer {
+  return Buffer.from(part.replace(/-/g, '+').replace(/_/g, '/'), 'base64');
+}
+
+function b64urlEncode(buf: Buffer): string {
+  return buf.toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
+}
+
+export function verifyJwtHS256(token: string, opts: VerifyOptions): JwtClaims {
+  const parts = token.split('.');
+  if (parts.length !== 3) throw new Error('malformed token: expected 3 segments');
+  const [headerB64, payloadB64, signatureB64] = parts;
+
+  // 1. Pin the algorithm — reject whatever the header claims if it isn't ours.
+  const header = JSON.parse(b64urlDecode(headerB64).toString('utf8'));
+  if (header.alg !== 'HS256') throw new Error(`unexpected alg: ${header.alg}`);
+
+  // 2. Recompute and compare the signature in constant time.
+  const expected = createHmac('sha256', opts.secret)
+    .update(`${headerB64}.${payloadB64}`)
+    .digest();
+  const provided = b64urlDecode(signatureB64);
+  if (expected.length !== provided.length || !timingSafeEqual(expected, provided)) {
+    throw new Error('invalid signature');
+  }
+
+  // 3. Only now is it safe to read claims as trusted.
+  const claims: JwtClaims = JSON.parse(b64urlDecode(payloadB64).toString('utf8'));
+  const now = opts.now ?? Math.floor(Date.now() / 1000);
+
+  if (claims.iss !== opts.issuer) throw new Error('issuer mismatch');
+  const aud = Array.isArray(claims.aud) ? claims.aud : [claims.aud];
+  if (!aud.includes(opts.audience)) throw new Error('audience mismatch');
+  if (typeof claims.exp === 'number' && now >= claims.exp) throw new Error('token expired');
+  if (typeof claims.nbf === 'number' && now < claims.nbf) throw new Error('token not yet valid');
+
+  return claims;
+}
+
+// Tiny demo helper to mint a token for local experimentation (NOT for production use).
+export function signJwtHS256(claims: JwtClaims, secret: string): string {
+  const header = b64urlEncode(Buffer.from(JSON.stringify({ alg: 'HS256', typ: 'JWT' })));
+  const payload = b64urlEncode(Buffer.from(JSON.stringify(claims)));
+  const sig = b64urlEncode(createHmac('sha256', secret).update(`${header}.${payload}`).digest());
+  return `${header}.${payload}.${sig}`;
+}
+
+// Example (fake secret — never hardcode real secrets; load from a secrets manager):
+//   const SECRET = process.env.JWT_SECRET!;
+//   const token = signJwtHS256(
+//     { iss: 'https://auth.example.com', aud: 'my-api', sub: 'user-123',
+//       exp: Math.floor(Date.now() / 1000) + 600 },
+//     SECRET,
+//   );
+//   const claims = verifyJwtHS256(token, {
+//     secret: SECRET, issuer: 'https://auth.example.com', audience: 'my-api',
+//   });

package/catalog/skills/secure-auth/references/auth-attacks.md

@@ -0,0 +1,76 @@
+# Common Auth Attacks and Defenses
+
+Most authentication breaches exploit operational gaps, not broken crypto. Know the named attacks and the
+specific control that stops each.
+
+## Credential stuffing
+
+Attackers replay username/password pairs leaked from *other* breaches, betting on password reuse. It is
+high-volume and automated.
+
+**Defenses:**
+- Rate-limit and progressively delay/lock by IP **and** by account.
+- Screen new/changed passwords against a breached-password corpus (HaveIBeenPwned range API or a local
+  Pwned Passwords list) — see `scripts/check-password-policy.mjs`.
+- Offer/require MFA; it neutralizes a correct-but-stolen password.
+- Add bot defenses (device fingerprinting, CAPTCHA on risk) for anomalous traffic.
+
+## Brute force
+
+Guessing one account's password through sheer volume.
+
+**Defenses:** account lockout / exponential backoff, strong minimum length, slow password hashing
+(argon2id), and MFA. Avoid hard permanent lockouts — they become a denial-of-service against legitimate
+users; prefer temporary backoff plus alerting.
+
+## Session fixation
+
+The attacker obtains or sets a session ID *before* the victim logs in, then rides the now-authenticated
+session.
+
+**Defense:** **regenerate the session identifier at every privilege change** (especially on login). Never
+accept a session ID supplied via URL/query string. Set `HttpOnly; Secure; SameSite` cookies.
+
+## CSRF (Cross-Site Request Forgery)
+
+A malicious site causes the victim's browser to send an authenticated, state-changing request to your app
+using the victim's cookies.
+
+**Defenses:**
+- `SameSite=Lax` (or `Strict`) cookies — blocks most cross-site sends.
+- Anti-CSRF tokens (synchronizer or double-submit) on state-changing requests.
+- Require a custom header / re-auth for sensitive actions.
+- Note: token-in-`Authorization`-header APIs (not cookie-auth) are largely immune, since the browser
+  doesn't auto-attach the header cross-site.
+
+## Account enumeration
+
+The app reveals whether an account exists via different responses, status codes, or **timing** on login,
+signup, or password reset.
+
+**Defense:** return identical responses and keep timing uniform regardless of account existence ("If that
+email is registered, we've sent a reset link.").
+
+## XSS-driven token theft
+
+Cross-site scripting that steals tokens from `localStorage` or readable cookies.
+
+**Defenses:** `HttpOnly` cookies (JS can't read them), a strict Content-Security-Policy, output encoding,
+and never storing long-lived credentials in web storage.
+
+## Phishing / MITM of credentials
+
+**Defenses:** phishing-resistant MFA (WebAuthn/passkeys bind to origin), HSTS, and never accepting
+credentials over plain HTTP.
+
+## Quick map
+
+| Attack | Primary control |
+|---|---|
+| Credential stuffing | Rate limit + breached-password screen + MFA |
+| Brute force | Backoff/lockout + slow hash + MFA |
+| Session fixation | Regenerate session ID on login |
+| CSRF | SameSite cookies + anti-CSRF token |
+| Enumeration | Uniform responses + timing |
+| XSS token theft | HttpOnly cookies + CSP |
+| Phishing | WebAuthn/passkeys + HSTS |

package/catalog/skills/secure-auth/references/oauth2-oidc.md

@@ -0,0 +1,65 @@
+# OAuth2 / OIDC — Flows and Validation
+
+OAuth2 is a **delegated authorization** framework: it lets your app obtain an access token to call an API
+on a user's behalf. OpenID Connect (OIDC) is a thin identity layer on top that adds an `id_token` so you
+also learn **who the user is**. For "log in with Google/Apple/etc.", you want OIDC.
+
+## Use Authorization Code + PKCE
+
+For both server-side web apps and public clients (SPAs, mobile), use the **Authorization Code flow with
+PKCE** (Proof Key for Code Exchange).
+
+```text
+1. Client generates code_verifier (random) + code_challenge = SHA256(code_verifier).
+2. Redirect user to /authorize?response_type=code&client_id=...&redirect_uri=...
+       &scope=openid profile email&state=<csrf>&code_challenge=...&code_challenge_method=S256
+3. User authenticates at the provider, is redirected back with ?code=...&state=...
+4. Client verifies returned state == sent state, then POSTs to /token with the code + code_verifier.
+5. Provider returns access_token (+ id_token for OIDC, + refresh_token).
+```
+
+PKCE binds the authorization code to the client that started the flow, so a stolen code is useless to an
+attacker who lacks the original `code_verifier`.
+
+## Flows to avoid
+
+| Flow | Verdict |
+|---|---|
+| Authorization Code + PKCE | **Use this** for web, SPA, mobile |
+| Client Credentials | Machine-to-machine only (no user) |
+| Implicit | **Deprecated** — tokens leak via URL/history; use Code+PKCE |
+| Resource Owner Password | **Avoid** — app handles the user's IdP password; defeats the point of delegation |
+
+## The `state` parameter (CSRF defense)
+
+Always send a random, unguessable `state` on the authorize request and reject the callback if the
+returned `state` doesn't match what you stored. Without it, an attacker can splice their own
+authorization code into the victim's session (login CSRF).
+
+## Validating the `id_token` (OIDC)
+
+The `id_token` is a JWT. Do not trust it until you verify:
+
+- **Signature** — against the provider's published JWKS (`jwks_uri`), matched by the `kid` header.
+- **`iss`** — exactly equals the provider's issuer.
+- **`aud`** — contains your client_id.
+- **`exp` / `iat`** — not expired; issued recently.
+- **`nonce`** — matches the nonce you sent (replay defense), when used.
+
+Never accept an unsigned token (`alg: none`) and never let the token dictate the algorithm — pin the
+expected algorithm server-side. See `examples/jwt-verify.ts` for the structural checks.
+
+## Scopes vs claims
+
+- **Scopes** (`openid profile email`) request *access* to categories of data.
+- **Claims** (`sub`, `email`, `name`) are the actual values inside the `id_token` / userinfo response.
+- Treat `sub` (subject) as the stable user identifier — `email` can change or be reassigned.
+
+## Checklist
+
+- [ ] Authorization Code + PKCE (not implicit, not password grant)
+- [ ] `state` generated, stored, and verified on callback
+- [ ] `id_token` signature verified against JWKS; `iss`/`aud`/`exp` checked
+- [ ] Algorithm pinned server-side; `alg: none` rejected
+- [ ] `sub` used as the durable user key, not `email`
+- [ ] `redirect_uri` allowlisted exactly (no open redirects)

package/catalog/skills/secure-auth/references/password-hashing.md

@@ -0,0 +1,70 @@
+# Password Hashing — argon2id, bcrypt, and tuning
+
+The job of a password hash is to make offline cracking of a stolen database *slow and expensive*. That
+is the opposite of a normal hash function's goal (speed). Never use `MD5`, `SHA-1`, `SHA-256`, or any
+fast hash for passwords — a single GPU computes billions of SHA-256 hashes per second, so an unsalted
+fast-hash dump is effectively plaintext within hours.
+
+## Algorithm choice
+
+| Algorithm | Status | Notes |
+|---|---|---|
+| **argon2id** | **Preferred** | Memory-hard; resists GPU/ASIC cracking. Tunable memory + time + parallelism. |
+| **bcrypt** | Acceptable | Mature, ubiquitous. 72-byte input cap; pre-hash long inputs with SHA-256. |
+| **scrypt** | Acceptable | Memory-hard; fine if argon2 unavailable. |
+| **PBKDF2** | Last resort | Only when FIPS compliance forces it; use a high iteration count. |
+| MD5 / SHA-* | **Never** | Fast = crackable. Not password hashes. |
+
+## Salting and peppering
+
+- **Salt** — a unique random value per password that defeats rainbow tables and stops identical
+  passwords producing identical hashes. argon2 and bcrypt generate and embed the salt for you; do not
+  add your own or store it separately.
+- **Pepper** — an optional secret key mixed in (or used to encrypt the hash) and stored *outside* the
+  database (e.g. in a secrets manager / HSM). It means a DB-only leak isn't enough to start cracking.
+  Manage it like any other secret (see the `secrets-management` skill).
+
+## Tuning cost parameters
+
+Pick parameters so a single verification takes roughly **250–500 ms** on your production hardware — slow
+enough to hurt attackers, fast enough not to DoS your own login endpoint.
+
+```ts
+import argon2 from 'argon2';
+
+const hash = await argon2.hash(password, {
+  type: argon2.argon2id,
+  memoryCost: 19456, // ~19 MiB; raise as hardware allows (OWASP baseline)
+  timeCost: 2,       // iterations
+  parallelism: 1,
+});
+```
+
+Cap input length (e.g. 128 chars) before hashing so an attacker can't submit a multi-megabyte password
+to exhaust CPU/memory — a cheap denial-of-service otherwise.
+
+## Rehash on login (parameter migration)
+
+Cost targets rise as hardware improves. On each successful login, check whether the stored hash used
+weaker parameters than your current policy and transparently rehash:
+
+```ts
+if (await argon2.verify(stored, attempt)) {
+  if (argon2.needsRehash(stored, currentOpts)) {
+    const fresh = await argon2.hash(attempt, currentOpts);
+    await users.update(id, { passwordHash: fresh });
+  }
+}
+```
+
+This lets you upgrade an entire user base's hash strength gradually without a forced reset.
+
+## Checklist
+
+- [ ] argon2id (or bcrypt) — never a fast/general-purpose hash
+- [ ] Per-password salt (library-managed), not reused or hand-rolled
+- [ ] Verification tuned to ~250–500 ms on prod hardware
+- [ ] Input length capped before hashing (DoS guard)
+- [ ] Breached-password screening at registration (`scripts/check-password-policy.mjs`)
+- [ ] Rehash-on-login to migrate parameters over time
+- [ ] Optional pepper stored outside the database

package/catalog/skills/secure-auth/references/sessions-vs-jwt.md

@@ -0,0 +1,69 @@
+# Sessions vs JWT — Storage, Expiry, Refresh, Revocation
+
+Both answer "how do we remember a logged-in user across stateless HTTP requests?" The decisive
+difference is **revocation**: server-side sessions are trivial to revoke; signed JWTs are not.
+
+## Server-side sessions (stateful)
+
+The server issues a random, high-entropy **opaque** session ID and stores the session state
+(user, expiry, CSRF token) in a database or Redis. The ID travels in a cookie.
+
+```http
+Set-Cookie: session=Gd8...n2; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
+```
+
+- **Revocation:** delete the server-side record — instant logout-everywhere.
+- **Expiry:** enforce both an idle timeout and an absolute lifetime.
+- **Trade-off:** requires shared session storage; a tiny lookup per request.
+- **Best for:** classic server-rendered web apps; anything needing reliable forced logout.
+
+## Stateless JWT
+
+A signed token (header.payload.signature) the client carries, usually in the `Authorization: Bearer`
+header. The server validates the signature and claims with no lookup.
+
+- **Cannot be un-issued.** Once signed, a JWT is valid until `exp`. There is no "delete the row."
+- **Expiry is your main control** — keep access tokens **short (5–15 min)**.
+- **Best for:** APIs and microservices that must validate auth without shared session state.
+
+### Access + refresh token pattern
+
+Pair a short-lived access token with a longer-lived **refresh token** that *is* tracked server-side so
+it can be revoked:
+
+1. Login issues a short access token (~10 min) + a refresh token (~days/weeks), refresh stored server-side.
+2. Client uses the access token until it expires.
+3. Client exchanges the refresh token for a new access token (and a **new** refresh token — rotation).
+4. Logout / compromise: delete the refresh token record; access dies within minutes.
+
+### Refresh token rotation + reuse detection
+
+On each refresh, issue a new refresh token and invalidate the old one. If an *already-used* (rotated-out)
+refresh token is presented again, treat it as theft: revoke the entire token family and force re-login.
+This catches a stolen refresh token because either the attacker or the victim will replay a consumed one.
+
+## Storage: where the token/cookie lives
+
+| Location | XSS-readable? | CSRF-exposed? | Verdict |
+|---|---|---|---|
+| `HttpOnly` cookie | No | Yes (mitigate w/ SameSite + token) | **Preferred** for browser auth |
+| `localStorage` / `sessionStorage` | **Yes** | No | Avoid — any XSS exfiltrates it |
+| In-memory (JS variable) | Only during session | No | OK for short access token in SPA |
+
+The headline rule: **never put a long-lived credential in `localStorage`.** `HttpOnly` cookies keep the
+token out of reach of injected JavaScript.
+
+## Quick decision guide
+
+- Need easy forced logout / session revocation, server-rendered app → **server-side sessions**.
+- Stateless API across many services, comfortable with short tokens + refresh rotation → **JWT**.
+- Hybrid is common and good: opaque session cookie for the web app, short JWT for downstream service calls.
+
+## Checklist
+
+- [ ] Access tokens short-lived (5–15 min)
+- [ ] Refresh tokens server-side, rotated on use, with reuse detection
+- [ ] Cookies set `HttpOnly; Secure; SameSite`
+- [ ] No long-lived credential in `localStorage`
+- [ ] Session ID regenerated on login (anti session-fixation)
+- [ ] Logout actually revokes server-side state, not just clears the client

package/catalog/skills/secure-auth/scripts/check-password-policy.mjs

@@ -0,0 +1,114 @@
+#!/usr/bin/env node
+// Runnable check: validates a candidate password against a configurable policy
+// (minimum length, character-class diversity, and a small breached/common-password
+// denylist). Zero dependencies — Node built-ins only.
+//
+// This is a *policy linter*, not a strength meter. It mirrors the kind of
+// server-side validation you should run at registration / password-change time,
+// BEFORE hashing with argon2id or bcrypt (see references/password-hashing.md).
+//
+// Usage:
+//   node check-password-policy.mjs '<password>'        # check one password
+//   echo '<password>' | node check-password-policy.mjs # check from stdin
+//   node check-password-policy.mjs --selftest          # run built-in test cases
+//
+// Exit code: 0 = password satisfies the policy, 1 = it does not (or selftest failed).
+
+// --- Policy configuration ---------------------------------------------------
+// NIST SP 800-63B favors length over composition rules and screening against
+// known-breached passwords. We keep a modest class requirement for demos but the
+// breached-list screen is the most valuable check in practice.
+const POLICY = Object.freeze({
+  minLength: 12,
+  maxLength: 128, // cap to avoid DoS on the hashing function
+  minClasses: 3,  // of: lowercase, uppercase, digit, symbol
+});
+
+// A tiny stand-in for a real breached-password corpus (e.g. HaveIBeenPwned's
+// k-anonymity range API or a local Pwned Passwords bloom filter). These are
+// obviously fake/illustrative entries used only to exercise the check.
+const BREACHED_COMMON = new Set([
+  'password', 'password1', 'password123', '123456', '12345678', '123456789',
+  'qwerty', 'qwerty123', 'letmein', 'admin', 'admin123', 'welcome', 'iloveyou',
+  'monkey', 'dragon', 'football', 'changeme', 'passw0rd', 'p@ssw0rd', 'test1234',
+]);
+
+// --- Validation logic -------------------------------------------------------
+export function countClasses(pw) {
+  let n = 0;
+  if (/[a-z]/.test(pw)) n++;
+  if (/[A-Z]/.test(pw)) n++;
+  if (/[0-9]/.test(pw)) n++;
+  if (/[^A-Za-z0-9]/.test(pw)) n++;
+  return n;
+}
+
+export function validatePassword(pw, policy = POLICY) {
+  const failures = [];
+  if (typeof pw !== 'string') {
+    return { ok: false, failures: ['password must be a string'] };
+  }
+  if (pw.length < policy.minLength) {
+    failures.push(`too short: ${pw.length} < ${policy.minLength} chars`);
+  }
+  if (pw.length > policy.maxLength) {
+    failures.push(`too long: ${pw.length} > ${policy.maxLength} chars`);
+  }
+  const classes = countClasses(pw);
+  if (classes < policy.minClasses) {
+    failures.push(`not enough character classes: ${classes} < ${policy.minClasses}`);
+  }
+  // Case-insensitive membership check against the breached/common denylist.
+  if (BREACHED_COMMON.has(pw.toLowerCase())) {
+    failures.push('matches a known breached/common password');
+  }
+  return { ok: failures.length === 0, failures };
+}
+
+// --- CLI plumbing -----------------------------------------------------------
+function check(label, pw) {
+  const { ok, failures } = validatePassword(pw);
+  if (ok) {
+    console.log(`OK ${label}: password satisfies policy`);
+  } else {
+    console.error(`FAIL ${label}:`);
+    failures.forEach((f) => console.error(`    - ${f}`));
+  }
+  return ok;
+}
+
+function selftest() {
+  // Each case asserts the *expected* verdict so the selftest catches regressions
+  // in either direction (a strong password wrongly rejected, or a weak one passed).
+  const cases = [
+    // name, password (obviously fake), shouldPass
+    ['strong_passphrase', 'Tr0ubadour&Horse-Battery!', true],
+    ['strong_mixed',      'X9k!mQ2$wLp7vZ', true],
+    ['weak_short',        'Ab1!', false],
+    ['weak_common',       'password123', false],
+    ['weak_one_class',    'aaaaaaaaaaaaaaaa', false],
+    ['weak_two_classes',  'lowercaseonly123', false],
+  ];
+  let allExpected = true;
+  for (const [name, pw, shouldPass] of cases) {
+    const { ok } = validatePassword(pw);
+    const correct = ok === shouldPass;
+    allExpected = allExpected && correct;
+    const mark = correct ? 'OK' : 'XX';
+    console.log(
+      `${mark} selftest ${name}: ${ok ? 'accepted' : 'rejected'} (expected ${shouldPass ? 'accepted' : 'rejected'})`
+    );
+  }
+  process.exit(allExpected ? 0 : 1);
+}
+
+const arg = process.argv[2];
+if (arg === '--selftest') {
+  selftest();
+} else if (arg !== undefined) {
+  process.exit(check('password', arg) ? 0 : 1);
+} else {
+  let buf = '';
+  process.stdin.on('data', (c) => (buf += c));
+  process.stdin.on('end', () => process.exit(check('stdin', buf.replace(/\r?\n$/, '')) ? 0 : 1));
+}