Demo
Rotate passwords safely, trust only signed alerts
Two small IT tools. A command rotates one service account’s passwords across five services, and says plainly which it changed, which need a person and which failed. An inbox takes alerts from a webhook that checks every signature, stores each message once and lets only verified company accounts read it.
This is a simulation. The services, the account, the alerts, the lines they come from and every number are invented, and everything runs in your browser: no password is changed, no message is sent, and nothing you do leaves your browser or is kept. The new passwords and the signing key are made at random in the page and never shown. Reloading the page starts again.
Part 1
One command, every service
The service account reports-bot is used by a reporting robot on five services. Each service plugs into the command through the same small adapter, with its own password rules. Try a dry run or the status first: neither changes anything. Then a live run.
The command
What will run
rotate --account reports-bot --dry-run
Terminal
Simulated
Nothing has run yet.
A manual step is waiting.
Audit record
None yet
Every run writes a record here: outcomes and times, never a password. The latest one is shown.
Part 2
Only signed alerts reach the inbox
Company alert lines send text messages to a webhook. The sender signs each request with a key it shares with the webhook, and the webhook stores a message only when the signature matches, once per message id. People read the messages in an inbox that updates as they arrive.
Send to the webhook
Nothing sent yet. The result of each request shows here, in the inbox and in the webhook log.
Inbox
0 unread
No messages yet. Send a signed alert.
Webhook log
Simulated
Every request is written here, the refused ones included.
Database rules
Enforced by the database, not by the app, so no app can get around them.
- Read messages: only verified accounts on the company domain.
- Change a message: only its read flag, and only by those same accounts.
- Add or delete a message: never from the app. Only the webhook stores messages.
What the demo shows
- One command across many services. Every service plugs in through the same adapter (status check, rotate, first setup), so adding a service never changes the command. You can run it on all five or only some.
- Each service’s own password rules. Every new password is made from your browser’s secure random source to that service’s length and character rules, and checked against them before it is used. The page never shows one.
- Dry run and status change nothing. Both say what they found or would do, and both still write an audit record.
- Honest outcomes. A service with no admin interface gets a manual step that waits for the operator to confirm it, and a service that fails is reported as failed, keeps its old password and makes the command end with an error code, with the command to try it again.
- An audit record with no secrets. Each record holds outcomes and times only, and after a live run the command searches it for every new password and reports that none is there. New passwords go to a single expiring, view-once handover, never to chat or email; this page makes no such link.
- A webhook that checks signatures. The signature is a real keyed hash (HMAC with SHA-256) worked out in the page with a key made when the page loads. A request with no signature, or one changed on the way, is rejected, and without its signing secret the webhook refuses everything.
- Stored exactly once. Each message is stored under its own message id, so a sender trying the same request again adds nothing.
- Access in the database rules. Only verified accounts on the company domain can read the messages or change their read flag, and nobody can add or delete one from the app.