From 28c77b7648b2a44a18be64ec44344d91cccfd742 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Thu, 15 Oct 2026 14:25:00 +0200 Subject: feat(auth): the recovery key never reaches the hub MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ticking "also e-mail it to me" at registration sent the recovery key R in the register body, and the hub appended it to the verification e-mail: the hub saw R in clear on its way out, and the resend door — no captcha — let anyone who knew a pending username and address have the hub mail a "recovery key" of their choosing. The box is gone. The recovery screen offers "E-mail it to myself", a mailto: link that opens the person's own mail application with the key filled in; the desktop shell hands mailto: to the system (http, https and mailto only) and the Android shell to a mail application (ACTION_SENDTO). The CLI drops --email-recovery-key and prints the key, as before. The hub mails the code alone, and refuses a register that still carries a recovery_key rather than dropping it, so an older client offering the option cannot tell someone their key was sent when it was not. A mailbox holding R remains, with the reset code that reaches the same mailbox, enough to recover the account's identities; the link says so, and it is the person's choice. Checked in Chrome and Firefox (headless, the real page against a stubbed hub) and by the CLI's end-to-end registration against a local hub. The Android change was not built here, and the desktop link was not clicked in the application. Co-Authored-By: Claude Opus 5.5 --- packages/meshbay-hub/src/meshbay_hub/static/keyderive.js | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) (limited to 'packages/meshbay-hub/src/meshbay_hub/static/keyderive.js') diff --git a/packages/meshbay-hub/src/meshbay_hub/static/keyderive.js b/packages/meshbay-hub/src/meshbay_hub/static/keyderive.js index bd5282c..bfbb94f 100644 --- a/packages/meshbay-hub/src/meshbay_hub/static/keyderive.js +++ b/packages/meshbay-hub/src/meshbay_hub/static/keyderive.js @@ -386,7 +386,7 @@ async function resealLegacyIdentity(keys, sessionKey, recoveryKey, { userId, nod * * Returns the raw private keys for immediate use after registration. */ -async function registerUser(username, email, password, recoveryMnemonic, captchaToken) { +async function registerUser(username, email, password, captchaToken) { // No keypair here any more. Identity keys are per node: one is generated the // first time this account joins a given node, encrypted under the passphrase, // and left with that node. So an operator who cracks what sits on their own @@ -397,10 +397,8 @@ async function registerUser(username, email, password, recoveryMnemonic, captcha const authKey = await deriveAuthKey(password, username); const payload = { username, email, auth_key: authKey }; - // The recovery mnemonic, when the user opted to have it e-mailed: the hub - // appends it to the verification e-mail and stores it nowhere - // (docs/MESHBAY_DESIGN.md §3.6). Omitted when they chose to save it themselves. - if (recoveryMnemonic) payload.recovery_key = recoveryMnemonic; + // Never the recovery mnemonic: the hub does not see it (docs/MESHBAY_DESIGN.md + // §3.6), and refuses a register that carries one. // The proof-of-work answer, when the hub asks for one. RegisterPage // (auth-page.js) works it out; this function just forwards it. A hub with // the check turned off gets nothing and does not look. -- cgit v1.2.3