← Dev log

security

A kiosk isn't a user

A kiosk isn't a user

Nobody types a password into a TV mounted in a waiting room. But that screen still has to be trusted to receive real data and submit real events. Treating a device as an anonymous public endpoint is unacceptable past a read-only display; treating it as a user that happens to be a machine doesn't fit either, because devices need provisioning, physical location and revocation in ways individual accounts don't.

So devices get their own table and their own lifecycle.

devices {
  code                    // "KIOSK-001"
  activation_code         // one-time code used to pair the physical device
  device_token_hash       // long-lived credential held after activation
  allowed_ip
  ip_restriction_enabled
  is_activated
  last_seen_at
}

Pairing, not trust-on-sight

A device isn't trusted because it's on the network. It goes through explicit activation: an admin generates an activation code for a specific device record, someone enters it on the physical device, and only then does the device receive a long-lived credential for future requests. It's structurally the same as pairing a smart TV — a short-lived one-time code exchanged for a long-lived credential.

device_token_hash, not the raw token, for the same reason passwords are hashed. A database with a plaintext credential lets an attacker impersonate any device immediately; the hash is useless for that on its own.

last_seen_at does two jobs. Operationally it tells me which kiosks and displays are actually online. As a security signal, a device that's gone silent for an unexpectedly long time — or is checking in from a very different pattern — is worth looking at: hardware failure, or something worse.

allowed_ip locks a device to a known network range. This is explicitly a secondary layer, not the primary defence — IPs can be spoofed and a device could legitimately move networks. The real authentication rests on the token; the IP check is a tripwire.

Why the extra caution

A laptop is something someone's actively holding and would notice behaving strangely. A kiosk in a public lobby is unattended for long stretches, which changes the threat model — physical tampering, someone swapping in a different device to impersonate a trusted one, outright theft are all more realistic than for a personal device. Explicit activation, revocable credentials and check-in monitoring are the right amount of paranoia for that. Stretching a normal user login to cover it would under-protect it.