Time-based Authentication Factors
You set up time based authentication factors by pairing a shared secret with a clock. Both the user app and the server check the same short code at login. Most engineering teams require these temporary codes before anyone can log in to production. Still, once a user passes that check, broad role permissions still allow risky commands. How time based authentication factors work in practice A time-based factor relies on two simple things: a secret key and the current time. When a user sets up a
TOTP (Time-Based One-Time Password) + Push-Based Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up time based authentication factors by pairing a shared secret with a clock. Both the user app and the server check the same short code at login. Most engineering teams require these temporary codes before anyone can log in to production. Still, once a user passes that check, broad role permissions still allow risky commands.
How time based authentication factors work in practice
A time-based factor relies on two simple things: a secret key and the current time. When a user sets up an account, the server creates a unique secret key. The user scans a barcode to save that key inside a mobile app. Both the server and the phone app now hold the exact same secret.
Every thirty seconds, the phone app reads the current clock time. It mixes the time and the secret key using a standard math formula. That math turns the two values into a short numeric code. When the user types the code at login, the server runs the same math. If both codes match within the current time window, the login succeeds.
Because the math depends on the clock, old codes expire after a few seconds. An attacker who steals a code from a screen cannot use it an hour later. The phone app also works offline because it only needs the local device clock. It never has to talk to a cell tower to build a valid code.
Where clock drift and shared roles cause issues
Teams often run into clock drift when they manage these login codes at scale. If a server clock runs two minutes slow, its math will not match the phone. Admins can widen the time window to accept slightly older codes during login. Widening that window helps users log in, but it also gives attackers more time.
Recovery workflows also create friction for support and security teams. When an engineer gets a new phone, they lose the local secret key. Admins must check the user identity and reset the factor by hand. Backup codes help, but users often store them in plain text files on laptops.
TOTP (Time-Based One-Time Password) + Push-Based Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login codes solve and what they miss
Time-based codes stop attackers who only have a stolen password. They prove that the person logging in holds the registered device right now. That single check blocks most automated credential stuffing attacks at the front door. Every team should require a second factor for all admin and developer accounts.
Yet a login code only checks identity at the start of a session. Once the server accepts the code, the login check is completely over. The user now acts with whatever role permissions the database or host grants them. If a developer logs in with a shared admin role, nothing checks their queries.
A valid login code cannot stop an engineer from dropping a production table by mistake. It also cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs. Also, server logs often show only the shared database role, not the specific person. Teams need controls that inspect individual commands and mask sensitive results during the active session.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What happens if a user device loses internet access?
The code generator app still works without internet or cellular service. It only needs the stored secret key and the internal clock on the device.
Why do valid time-based codes sometimes fail at login?
Codes fail when the device clock and the server clock fall out of sync. Syncing both clocks to standard network time fixes the mismatch right away.
Do time-based login codes restrict what a user can run after login?
No, a time-based factor only checks who is logging in at the start. After login, the user can run any command allowed by their assigned role.