Your server stores each sensor's long-lived refresh credential in a table — why store a hash of it, and one row per device?

Forty thousand battery-powered sensors sit in freezers, trucks and depots. Each holds a long-lived refresh credential and, when it wakes on a weak radio link, trades that credential for a short-lived one it uses to post temperature readings. Server-side there is a table with one row per sensor, and the first thing a reviewer asks is what is actually in that row. ## The table you are really building A refresh credential is a **bearer** credential: possession is authority. If the column holds the credential itself, the table is not a set of records *about* credentials — it is forty thousand usable credentials in one place, reachable by every path that reaches a database: - a nightly dump sitting in object storage; - a read replica an analyst can query; - an injected predicate on some unrelated endpoint; - a support engineer with production read access; - a restore copied to a laptop for a debugging session. Storing a **digest** changes what all of those are worth. The server hashes the value the sensor presented and looks the row up by that digest. It never needs the original back, so it never has to keep one. ## Why a fast digest and not a slow verifier hash Password storage reaches for a deliberately slow, per-row-salted function because a human-chosen password has perhaps 20-30 bits of real entropy and can be guessed offline. A refresh credential is machine-generated with 128-256 bits from a cryptographic generator: there is no dictionary and no offline guessing, so stretching buys nothing. A single fast digest such as SHA-256 is the right tool, and it has one property the slow one lacks — it is **deterministic**, so the digest of the presented value is a lookup key. A per-row salt would destroy exactly that: with a different salt per row, finding the row means trying every row. The honest alternative, if you do want a salted slow hash, is to issue the credential as two parts — a public identifier you index on, and a secret you verify — which is how long-lived machine keys are usually shaped. Either design works; what does not work is a salted hash with nothing else to find the row by. | storage choice | what a leaked read gives | can the console show it again | lookup | |---|---|---|---| | the credential in plain text | every sensor's live credential | yes | index on the value | | reversibly encrypted | every credential, once the key leaks too | yes | index on the ciphertext | | fast digest | device identities and lifetimes, nothing presentable | no | index on the digest | ## The column you must not add The temptation is a reversible copy so an operations console can re-display a credential a technician mislaid. That single column puts the whole table back into the first row of the table above, because the key that decrypts it lives in the same deployment that reads it. The correct answer to a mislaid credential is re-enrolment: mint a new one, hand it over once, revoke the old row. ## One row per device, not one per subject One row per device is a revocation decision before it is a schema decision: 1. **Targeted kill.** A sensor recovered from a skip with its flash read can lose its own credential while its depot siblings keep reporting. 2. **No rotation race.** If four sensors share a row, every rotation invalidates the other three's copy, and you get a storm of false replays on a link that already retries. 3. **Attribution.** The row records which device last presented, and when — the only evidence you will have when something looks wrong. 4. **Clean re-enrolment.** A replaced radio board gets a new row rather than mutating a shared one. ## What hashing does not do Hashing the stored credential protects the *table*. It does nothing about a short-lived token already minted from that credential and already in flight. Revoking the row stops future mints immediately; the token the sensor (or a thief) is holding keeps being accepted by verifiers until its own `exp` passes — minutes, typically — unless verification also consults a suppression list. That gap is the revocation lag, and it is a separate piece of bookkeeping from the row you just hardened.