Seven shapes that are correct for a window and wrong outside it, plus the two ways that window is written down. If you have not read how a card is laid out, start there.
The other families on this site document strings that keep their meaning. An onion address is the same address next week. A key fingerprint is the same run of hex for as long as the key exists. A transaction id refers to the same record for good. The shapes collected here do not behave like that. Each one is a value that is right for a period and worthless outside it, and none of them carries that period in its characters.
That changes what a format check is worth. Everywhere else on this site, a shape works as a filter: it removes strings that cannot possibly be what they claim to be, and leaves a smaller pile you still cannot vouch for. Here the filter is weaker again, because the thing that decides whether a session value is right is almost never visible. Six digits are six digits at the second they are accepted and six digits an hour after they stopped being accepted. Not one character moves.
So the usual question, is this the right shape, answers less than it does elsewhere. It still catches the loud failures: a code that lost a leading zero, a cookie line broken by a stray comma, a time printed with no offset, a paste that carried an invisible character. It cannot catch the quiet ones, and the quiet ones are the normal case in this family.
Opacity is the point, not a side effect
Three of these shapes are deliberately unreadable. A captcha token, a cookie value and the token inside a link are all designed so that looking at them yields nothing. There is no version field, no issued date, no account name hidden in the middle. Whoever built the value wanted an onlooker to learn nothing from it, and they succeeded, which means you learn nothing from it either.
That is worth stating plainly because it defeats the instinct these pages otherwise encourage. On an address or a key block, close reading pays: the length, the last character, the prefix, the line width all carry information. On an opaque session value there is nothing to read closely. You can confirm the alphabet and count the run, and then you have finished.
Two of these are not credentials at all
A printed timestamp and a plain epoch integer sit in this family because they are the readable form of the clock the rest depend on. They are not secrets and nothing is lost by writing one down. They are here because when a short lived value behaves oddly, the explanation is usually a disagreement about time, and a disagreement about time shows up first as a printed string somebody has misread.
A password is the other outlier. It does not expire on a schedule, and it is the only shape on the site you are never shown while you type it. It is documented here anyway, because its shape rules are the same kind of rule as the rest of this family: constraints imposed by a store you cannot see.
- A captcha tokenThe short answer you type, and the opaque value that answer produces on the far side
- A session cookieA name, an opaque value and a fixed vocabulary of attributes on one line
- A passwordThe one shape you never see while you type it, described through the field around it
- A one time codeSix digits, sometimes eight, where the first character may be a zero that matters
- A timestamp printed on a pageA moment written as text, complete or ambiguous depending on one trailing field
- A time written as a plain integerA run of digits counting seconds, indistinguishable from any other number of that width
- A link with a token inside itA URL where an opaque run in the path or the query is itself the secret
Where the window comes from
Values in this family stop being correct in one of two ways, and telling them apart explains most of what you will see.
The first way is a stored record. Somewhere on the far side there is a row that says this value exists and is still current. It ends when that row is deleted or marked spent. Cookies, captcha tokens and link tokens work this way. Nothing about the string changes when it dies; the string is a lookup key and the answer to the lookup changed.
The second way is a calculation from a clock. Nothing is stored. The value is computed from the current time and a shared starting point, so the same input produces a different answer as the clock moves. A one time code works this way. It is not revoked, it simply stops being the answer.
This matters for a plain reason. A stored value can be ended early by the far side and you will never see why. A computed value cannot be ended early at all, but it will fail if the two clocks involved have drifted. Same symptom, different cause, and the characters of the string are silent on which one you met.