Leak Nothing on a Non-Matching Sign-In

Who / when: anyone — including someone probing the patient sign-in page who is not a patient. This page documents a deliberate security behaviour rather than a task: when sign-in details do not match a real record, Veona answers with the same neutral confirmation it gives a genuine patient, revealing nothing. A login screen that said “no such patient” or “unknown phone number” would quietly confirm who is a patient and at which facility; Veona refuses to be that oracle.

A couple of terms:

• Sign-in combo — the three details the patient app asks for instead of a password: Last name, Date of birth, and the last 6 digits of your phone.
• Account enumeration — the attack this prevents: poking a login page with guesses and reading the differences in its replies to learn which accounts (or facilities) exist. The defence is to make every reply identical.

We will follow a would-be prober trying made-up details on the public sign-in screen.

1. The prober — opens the patient app’s “Sign in to your portal” screen, which asks only to “Confirm a few details and we will send you a secure link to your email on record.” No password field exists to brute-force.
2. The prober — types a guessed “Last name”, a “Date of birth”, and six digits into “Last 6 digits of your phone”, then presses “Email me a sign-in link.”
3. The prober — lands on the “Check your email” confirmation. Because the combo did not match any record, the message is the neutral form: “If these details match a record, we’ve sent a secure sign-in link to the email on file. The link is single-use and expires shortly. For your security, we don’t show your full address.”
4. The prober — learns nothing. There is no masked email shown, no patient name, no facility named, no “not found”, no different wording, and no different timing that would betray a hit. Wrong details and right details look and read the same.

Note

What a real patient sees is intentionally close — but not identical in the one safe way. On a genuine match, the same confirmation appears, and the only addition is an aggressively masked address (for example a••••@g•••.com) so the patient can recognise their own inbox — never the full address. No reply ever exposes a patient’s identity, and no reply ever tells an outsider whether a record exists. The real patient’s full journey from this screen is Sign In Passwordless With a Magic Link.

Caution

There is no list to scrape and no error to mine. The secure sign-in link only ever goes to the email already on file for a matching patient — never to an address typed on the form — so a guess cannot redirect a link to the prober. And because there is no password, there is no password to spray or steal.

What happens next

Nothing is disclosed and nothing changes for any patient. A genuine patient who mistypes simply presses “Use different details” and tries again; the neutral confirmation is harmless either way. If someone has truly lost access to the email on file, the screen points them to contact the care facility to update their details — Veona will not change them online. This same no-leak principle runs through the rest of the portal’s identity surface, including recovery, covered in Sign In, Reset and Recover a Portal Account.

Follow the trail

• Next: Sign In Passwordless With a Magic Link
• Related: Sign In Passwordless With a Magic Link · Sign In, Reset and Recover a Portal Account