No account, no password: recalling a record without a login
The most secure credential is often the one you never issued. For a system used once or twice a year, an account is a liability. Here is how we let a traveler retrieve their submission without one.
Engineering Practice
Ask a traveler to create an account for a form they will touch once this year and again maybe next year, and you have built three problems at once: a password they will forget, a credential you now have to store and protect, and a recovery flow that becomes the softest part of the whole system. For a single, time-bounded interaction, the account is not the feature. It is the risk.
So for the Belize travel declaration we did not build one. On submit, the traveler is given a short confirmation code and nothing to remember beyond it. To pull the record back up, they present that code together with a second factor they are already carrying: the passport the declaration is about. No username, no password, no reset link in an inbox.
Two factors, neither of them a password
A bare code would be a bearer token: anyone who saw it could open the record. So recall requires two things together, the code and a passport detail, and the server only answers when both match the same record. The code is something the traveler was handed; the passport is something they hold. Knowledge plus possession, without ever minting a secret we have to store.
Making the code safe to be short
Two controls do the heavy lifting. First, every lookup is rate limited per code and per caller, with a lockout, so an automated sweep across the code space is throttled to uselessness long before it lands a hit. Second, a wrong code and a right-code-wrong-passport return the exact same answer: not found. There is no response that tells an attacker they are getting closer, so the search space gives back no signal to climb.
- Uniform responses. A mismatch on either factor yields one indistinguishable result, so the endpoint is never an oracle that confirms a real code.
- Throttle and lock. Per-code and per-caller limits with a lockout turn brute force into a wall, not a slope.
- Signed, not just stored. The confirmation the traveler holds is cryptographically signed, so a fabricated or altered code is rejected without even reaching the data.
- Nothing reusable in transit. The code is never placed in a URL, a log line, or a QR payload where it could be captured and replayed.
Why this is the safer design
An account you never created cannot be phished, reused across sites, leaked in a breach, or left logged in on a shared kiosk. There is no password database to spill and no recovery flow to socially engineer. The credential is scoped to exactly one record, useless anywhere else, and only meaningful when paired with a document the rightful traveler already holds.
The strongest account is the one you never had to issue. Less to store, less to steal, less to get wrong.
This is data minimization applied to identity itself. We collect no standing credential because the interaction does not need one, and the thing we do not hold is the thing that can never be taken from us. For a system a person meets briefly and rarely, that is not a compromise on security. It is the more honest version of it.