Security FAQ

Words are invented, not dictionary words: a consonant start, one to three short middle sounds, and a two-letter ending (for example brinter, solvra, klavuria), 6–9 characters. The generator's theoretical space is ~571,000 distinct words (about 19 bits). After screening out profanity and dictionary collisions, the pool we actually assign from holds roughly 50,000 words (about 15–16 bits).

We'll say it plainly: that is modest entropy— comparable to a short PIN, far below a strong password. A word is a convenience factor, not a high-entropy secret. Everything below exists because we assume a word can eventually be guessed, and make that knowledge insufficient to sign in.

Every word is unique to one person. Words are drawn from a pool table with a database-level uniqueness constraint, and assignment claims a word atomically — two people racing for the same word, one wins and the other is offered a different one. Because words are unique, their hashes are unique, so there is no ambiguity about which account a hash belongs to.

Three layers, in order of importance:

• Device binding. A correct word presented from a device that isn't your enrolled device does not sign in — the server refuses it and routes to phone approval. So even a fully guessed word grants nothing without your physical enrolled device.
• Rate limits with backoff. Every sign-in attempt is throttled on two dimensions before any expensive work happens. Per source IP: 20 / minute and 100 / 15 minutes. Per specific word value: 6 / minute and 15 / 15 minutes. Over a limit returns 429 with a Retry-After backoff. The same limiter covers every other endpoint too — word rotation, invite redemption, phone-approved sign-in, the SDK's server-to-server calls, and the public waitlist and pilot forms — so no route is left unmetered.
• Single-use tokens. A successful sign-in yields a short-lived token spendable exactly once (see replay, below).
• No enumeration oracle. A correct word on an unrecognized device and a word that doesn't exist return the identical response. The sign-in endpoint never creates accounts — enrollment happens only through onboarding — so an attacker can't use it to confirm whether a word is real.

These are enforced in the protocol host and applied before the Argon2id hash, so guessing stays cheap for us and slow for an attacker.

Stored word records are one-way hashes, computed with Argon2id — the memory-hard function OWASP recommends — at memory 19 MiB, iterations 2, parallelism 1. The client sends only a SHA-256 pre-hash; the server applies Argon2id to that.

Critically, the hash is computed under a server-side pepper (a secret held only in our server environment, never in the database). An attacker who steals the database but not the pepper cannot test guesses at all. Given the modest word entropy, the pepper is the load-bearing control offline — Argon2id's memory-hardness raises the cost further, but the pepper is what makes a stolen database useless on its own. We treat the pepper as a top-tier secret.

The SHA-256 pre-hash is sensitive in transit: it travels over TLS, and anyone who captured it could send it to the sign-in endpoint. What limits its usefulness:

• Device binding means a captured pre-hash replayed from a different device is refused — it routes to phone approval rather than authenticating.
• The issued token is single-use. Each successful auth mints a token bound to one business with a unique id that is spent on first verification; a replayed token is rejected with 409.
• Rate limits cap how many times any single pre-hash value can be tried.

Being fully honest: the pre-hash is not a public value, and an attacker who holds both your pre-hash and your enrolled device is in the same position as someone who knows your word on your device — the same trust boundary as any device you own. Hardware-backed device keys (roadmap, below) will replace the pre-hash-over-TLS model with a per-request device signature that can't be replayed at all.

Today WordKey binds an account to a single enrolled device. If that device is lost, two things are true:

• Anyone who has both your unlocked device and your word can sign in — the same exposure as any device that stays signed into your accounts. Your device's own lock screen / biometric is the first line of defense.
• You rotate your word (which requires your current word) to cut off a device you no longer trust, and re-enroll your new device.

We're candid that single-device enrollment is a limitation. The roadmap below addresses it directly.

Because WordKey holds no recoverable copy of your word — not even an encrypted one — there is nothing to recover. If you forget your word, no one, including us, can retrieve it. Instead you rotate: from your enrolled device, with biometric confirmation and your current word, you pick a new word. It propagates to every connected site instantly and the old word stops working immediately. This is a deliberate trade: non-recoverable storage is what makes a breach yield nothing, and the cost is that recovery must mean replacement.

• Hardware-backed device keys in the secure enclave, replacing the pre-hash-over-TLS model with per-request signatures that can't be replayed.
• Multi-device enrollment with per-device revocation, so losing one device doesn't force a rotation.
• WebAuthn / FIDO2 layering for regulated deployments, and an independent third-party protocol audit.

These are planned, not shipped. We label roadmap items as roadmap.