Account Recovery

Browser verification on a Storm account means a six-digit code sent to your verified email address after your password. It is on for every account with a verified address, and there is no switch. This page is what happens when that code cannot reach you. Read it before you need it.

What a lockout costs

Nothing on the data side. Your access keys keep working, your buckets keep serving, and any S3 tooling pointed at them carries on. What you lose until you are back in is account management: the dashboard, key minting, bucket changes, billing. That is why the slow path below can afford to be slow.

First: recovery codes

At your first sign-in after your address was verified, Storm showed you ten recovery codes, once, and asked you to confirm you saved them. Each works one time in place of the email code. On the sign-in code page, open More options and enter one.

Your profile's Security card shows how many remain and warns you at three and at one. A set is issued once: there is no way to ask for a new one, so keep them somewhere that survives a lost laptop. If you run out, the ways back are the inbox and the key proof below; completing an account recovery issues a fresh set.

Second: prove you hold an access key

No inbox and no codes left: prove control of the account with a live account key, the same key your S3 tooling uses. Storm never sees the key's secret. It watches for a request the key signs.

1. POST /buckets/api/recovery/start/ with {"username": "...", "key_id": "GK..."}. The reply carries a nonce and an object name, storm-recovery-<nonce>.

2. Within fifteen minutes, make one GET or HEAD request for that object name in any bucket the key can reach, signed with that key. The object does not exist, so the answer is a 404, and the 404 is the proof: Garage checks the signature before it looks for the object, so only a request signed with the key's secret gets one. A request with the key id and a wrong secret gets a 403, which proves nothing.

3. POST /buckets/api/recovery/verify/ with the same username, key id and nonce.

A key that has been revoked, or that has never been used, does not count: a key minted for later and never put to work cannot be evidence, because evidence is a request it made. Per-bucket keys do not count either; only account keys identify the account. The two calls answer the same way whether or not the account or the key exists.

A not_seen answer from verify lists every reason that produces it, the same list for everyone: a mismatch or a proof older than fifteen minutes, a key that does not count, a request that was not signed with the key or did not get a 404, a request that has not reached Storm yet (logs ship within about a minute, try again), or a storage node whose agent does not yet report request status. Storm does not enable this path on a node until its agent does, so the last one should never be the reason; if it is, that is a Storm fault and the fix is on Storm's side.

The 24-hour window

A verified proof does not sign you in. It opens a 24-hour window, and the address on file is told: what was requested, which key signed it, when it takes effect, and a link to cancel. A signed-in owner can also cancel from the Security card on their profile.

If the request was not yours, cancel it. The key that signed it is killed on the spot, because a cancelled recovery is evidence that key is in the wrong hands, and anything still using it stops working right then. Its buckets move to a replacement key, and the notice names it. That replacement has no secret you can use yet, because a secret is shown once on the dashboard and nobody was signed in to see it: sign in, open Account keys, and rotate the replacement to receive one.

If nobody cancels, call verify again after the window elapses. The reply carries a one-time link, good for ten minutes, that signs you in to a recovery session. If a session's hour passes without the click, prove control again and the window hands over a fresh link. A window nobody claims closes on its own seven days after it took effect; proving control after that opens a new window, and the address on file is told again.

The recovery session

That session lasts one hour and can do exactly one thing: put a new email address on the account. It sends a confirmation to that address. Nothing about the account changes until you click that link, and the link dies with the session: give up, or let the hour pass, and the account is exactly as it was.

Clicking the link, in one step: the new address goes on the account as verified, your recovery codes are voided, and every remembered browser is forgotten. The old address is told. Sign in with your password; that sign-in asks for a code at the new address and hands you a fresh set of recovery codes.

When nothing is available

No inbox, no codes, and no access key that has ever been used: Storm does not recover the account. There is no operator override and no manual identity check, and that is a property of the system rather than a gap in it. A support conversation cannot be the thing that lets someone into your account.

An account that never minted a key never moved data through the API, so it holds nothing you cannot recreate by signing up again.