Getting in / Pair 12 of 41
A code that does not match against a clock that does not
Six digits go in and come back refused. The code was correct arithmetic either way, so the question is whether the arithmetic was done at the right moment.
A one off slip in the entry
A digit went in twice, a digit went missing, or the code rolled over between reading it and sending it. The device is healthy and the shared secret is intact. What failed was a single entry, and the next one will very likely work.
The right secret at the wrong moment
The device that generates codes has drifted away from the time the market is keeping. It is still doing correct arithmetic with the correct secret, and every answer it produces is for a moment that has passed or has not arrived. Nothing about the account is broken.
Why a wrong code and a wrong clock refuse alike
A time based code is a number worked out from two things. A secret shared between your device and the market when you set the second factor up, and the current time chopped into thirty second steps. Feed the same secret and the same step into the same arithmetic on both sides and you get the same six digits.
The check at the other end compares the digits it expects against the digits you sent. It has no way of knowing why they differ. A code that was fat fingered and a code that was worked out for a step three minutes ago fail in the same place, with the same message, and there is nothing left over to inspect.
Where the comparison actually happens
Nothing about your code travels except the six digits. The market does not see your device, your secret or your clock. It works out what it thinks the answer should be for the step it is in, allows a step either side, and compares. That is the whole of it.
Which means the failure is always one of two shapes. Either the digits you sent were not the digits your device produced, or your device and the market are not standing in the same thirty second window. The first shape is a slip. The second is a measurement problem, and it will keep happening until the measurement is fixed.
| What you notice | Points at the clock | Points at the entry |
|---|---|---|
| How many have failed | Every one, with no exceptions | One or two, with successes in between |
| When it started | After a restart, a flat battery, a long flight or a manual time change | After a rushed entry or a code caught late |
| Other time based things | Timestamps and alarms also look off | Behaving exactly as normal |
| A fresh code taken slowly | Refused as well | Accepted |
The thing that tells a drifted clock from a bad secret
Compare seconds, not minutes
Put the clock on the code generating device next to a clock you trust and compare the seconds, not the minutes. Anything past half a minute of difference is enough to refuse every code you will ever produce on that device.
- Find the seconds display on the device that makes the codes.
- Put it beside a clock you have reason to trust, on another device or elsewhere.
- Watch both roll over. A difference you can see is a difference that matters here.
- If they roll together, the clock is not your problem and the next careful entry is the answer.
Notice that this test never spends an attempt. That matters, since a run of refused codes lands you behind the same counter described in rate limiting against a wrong password, and once two refusals are stacked you cannot read either of them.
The expensive direction here
- If you treat a drifted clock as a bad code
- You keep entering fresh codes that cannot pass, spend your attempts, and eventually decide the second factor is broken. That is the point at which people go looking for a way to re-enrol it, in a hurry, and re-enrolling a second factor from a page you found while frustrated is about the worst evening available.
- If you treat a bad code as a drifted clock
- You go and look at a clock for two minutes and find nothing wrong with it. The cost is two minutes and mild embarrassment, then you take one careful code and get in.
It is hard to think of a pair in this section where the gap is wider. One direction costs you a couple of minutes of looking at a phone. The other ends with somebody dismantling a working second factor to solve a problem that a time setting would have fixed. When in doubt, check the clock first, since it is the cheap move.
What each one needs from you next
- If it is the entry
- Wait for a fresh code rather than chasing the last seconds of a dying one, type it in one go, and send it. Codes read at the end of their step are the most common slip of the lot.
- If it is the clock
- Correct the time on the device that generates the codes, by hand or by letting it sync, then take a single attempt. Do not touch the secret and do not remove the second factor.
Two smaller habits remove most of this pair from your life. Read codes at the start of a step rather than the end, and leave the code device set to sync its time automatically. Everything else in this section is about refusals decided by somebody else, which makes this one unusual. Here the refusal is decided by arithmetic, and arithmetic can be argued with.
Questions readers send about this pair
Why did my codes stop working all at once?
A clock that moves in one jump, usually after a restart or a battery going flat, will take every code with it. Nothing gradual happened to the secret. The device simply stopped agreeing with everybody else about what time it is.
Do I need an internet connection for the codes?
No. The arithmetic happens entirely on the device. The only thing a connection helps with is keeping the clock honest, which is exactly the part that breaks this pair.
Is a refused code a sign the account was interfered with?
It is very weak evidence at best. Refused codes are far more often a step boundary or a drifted clock, and the clock takes two minutes to rule out before you consider anything more dramatic.