Certificate-based TOTP Authentication
You set up certificate based totp authentication by pairing a digital file with a code. The server checks both items before it lets a user log in. Many teams use this method to protect databases and Linux hosts. They issue a key file and link an app that makes six-digit codes. Still, teams often grant broad admin roles after that login passes. Once inside, a user can run any command or read any table. How certificate based totp authentication works This login method combines two distinct proo
Certificate-Based Authentication + TOTP (Time-Based One-Time Password): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up certificate based totp authentication by pairing a digital file with a code. The server checks both items before it lets a user log in. Many teams use this method to protect databases and Linux hosts. They issue a key file and link an app that makes six-digit codes. Still, teams often grant broad admin roles after that login passes. Once inside, a user can run any command or read any table.
How certificate based totp authentication works
This login method combines two distinct proof steps during the initial handshake. First, the client machine presents a signed digital file to the server. A central trust server signs this file in advance for a specific user. The target system checks the signature and the expiration date on the file. It rejects the user right away if the file is old or untrusted.
Next, the server asks the user for a time-based one-time code. The user opens an app on a phone or hardware token. That app shares a secret seed and the current clock time with the server. It calculates a short code that changes every thirty seconds. The user types this six-digit number into the login prompt. The server runs the same math and compares the two numbers. When both the file and the code match, the login succeeds. This dual check stops attackers who only steal a laptop or a phone.
Managing keys and clock sync across teams
Running this setup requires steady care from the security team. You must build a root trust server to sign every user file. If you set long expiration dates, you must maintain a revocation list. Every target host needs a fresh copy of that revocation list every day. Otherwise, a former worker might still pass the first check with an old file.
Short file lifetimes reduce that risk, but they require automation to renew keys. You also have to manage the secret seeds for the six-digit codes. When a developer buys a new phone, an admin must reset their seed. Also, every server clock must stay in sync with standard network time. If a server clock drifts by two minutes, valid codes will fail. Admins then spend hours fixing time sync bugs so engineers can work.
Certificate-Based Authentication + TOTP (Time-Based One-Time Password): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What happens after the login check passes
Pairing a signed file with a timed code solves the front-door problem. You know with high certainty who sits at the keyboard during login. This stops credential stuffing and phishing attacks cold at the perimeter. Auditors like this setup because it proves strong user identity checks.
Yet login checks only decide who enters the system at the start. They do not inspect what happens during the rest of the session. Once a database or host accepts the login, the user gets a static role. A developer with write permissions can drop a table or read all customer rows. Native login tools cannot block a risky query or rewrite emails and card numbers. They also do not ask a manager to approve a single dangerous command. To control actions in flight, teams need controls that work at the command level.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why combine a digital file and a timed code?
A digital file proves the device is trusted, while the code proves user presence. An attacker needs both your unlocked computer and your phone to log in.
What happens if a server clock drifts out of sync?
Timed codes rely on matching clocks between the phone app and the server. If the server clock drifts too far, it will reject valid six-digit codes.
Does dual login protect sensitive data inside a database?
No, login checks only verify identity before the session starts. Once inside, the user can read any emails or phone numbers their role allows.