Treat a Secret Account Number as a Credential: Audit It

A field labelled account number is not automatically a public reference, and the label is not the test. The test is what possession permits: if knowing the number signs someone in, downloads a connection profile, or authorizes a device, that number is a credential with a lifecycle. I run the five checks below whenever a service hands out a numeric identity and calls it harmless. Each one produces a line in a short record, and the record is the deliverable, not a verdict about the product.

Inventory what possession actually grants

Write down every action the number unlocks, separately. Signing in to a portal, retrieving a configuration file, authorizing a new device and supplying an accepted tunnel login are different authorities, and a service can implement one without the others. A portal that accepts the number as the only field tells you nothing about how the tunnel authenticates its peer later or how traffic keys are derived.

The general model is easy to state: a bearer credential is one where the holder can use it without proving possession of a separate cryptographic key, which is the distinction RFC 6750 draws for tokens. That is a comparison, not a claim that a number-based service implements OAuth. If the holder needs nothing else, treat the number as a bearer secret and classify the rest of the design accordingly.

Protect it like a secret, not like a reference

Storage follows from the classification. A value that signs in belongs in a password manager, not in a screenshot, a clipboard history, a chat message or a browser note. Screenshots are the usual leak: the number is short and looks harmless, so it ends up in a support thread that outlives the device it came from.

Phishing is the other failure mode, and it does not care how random the number is. An impostor who wants the value will ask you to paste it into a form, and a credential that never expires and has no second factor is worth the effort. Reach the login path from a bookmark or a known address, not from a link in a message that also asks for the number.

Treat recovery material as part of the secret. If the operator also issued a recovery code, a PIN, or an email address that can reset the account, those are separate credentials with the same protection requirement. One unprotected reset channel turns every other control into decoration.

Check guess resistance and rate limiting together

Length is only meaningful next to the generation method. A long number produced by a predictable sequence is weaker than a short value produced by a cryptographic generator, and an impressive digit count does not establish unpredictability. Ask how the value is generated before you reason about how hard it is to guess.

Guess resistance alone also does not survive an unlimited attempt rate. The controls that matter are the ones the operator implements: failed-attempt counters, lockouts, per-source throttling, and whether a wrong number is distinguishable from a nonexistent one. If the service supports it, one failed attempt tells you what the error looks like and whether a retry counter appears:

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

Record what the response reveals. A distinct error for an unknown account is an enumeration oracle even when the number is unguessable, and that finding belongs in the record whether or not you can fix it from the client side.

Plan rotation and revocation before you need them

Find the supported process for a lost or exposed number and write it down while everything works. Can the account credential be replaced at all? Does replacement invalidate already enrolled devices, active sessions, or downloaded configuration? Which recovery material does the process demand? A service without an email dependency may transfer more recovery responsibility to the user, which makes the procedure more important, not less.

Separate account replacement from credential revocation. If the number authorizes downloading a key, certificate or profile, replacing the number may leave that downloaded material valid, and revoking the downloaded material may be a different operation with a different owner. Do not assume one changed field terminates every connection; check the operator's actual model and note where you verified it.

Document the decision and recheck it later

Keep a one-page record per service: which authorities the number grants, where it is stored, who can reset it, what evidence of use exists, and what you would do in the first hour after disclosure. That record is what turns an argument about terminology into a decision someone can audit.

Privacy claims need their own scope. A randomly generated number can still be a stable identifier that links account events across time; unpredictability is not unlinkability, and neither property says anything about retained network metadata. Compare complete designs rather than counting fields on a login screen.

Before you file it:

• Every authority the number grants is listed, including downloads and device authorization.
• Storage and recovery channels are protected to the same standard as the number itself.
• The generation method and the rate limits are known, not assumed from length.
• A replacement procedure and a revocation procedure exist, and you know which one cancels which.
• The record names who can reset the value and what evidence remains after use.