Two-factor Model
You set up a two factor model by pairing a password with a second check. The user must pass both checks before the system opens a database session. Most teams start by linking their database roles to a single sign-on provider. That provider asks for a password and a temporary code from a phone app. Still, once a user logs in, broad database roles still allow risky commands. A stolen session or a mistake can expose or delete whole tables at once. How a two factor model works for database roles
Multi-Factor Authentication (MFA) + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a two factor model by pairing a password with a second check. The user must pass both checks before the system opens a database session. Most teams start by linking their database roles to a single sign-on provider. That provider asks for a password and a temporary code from a phone app. Still, once a user logs in, broad database roles still allow risky commands. A stolen session or a mistake can expose or delete whole tables at once.
How a two factor model works for database roles
A two factor model checks two separate proofs of identity at login time. The first factor is something the user knows, such as a standard password. The second factor is something the user has, like a hardware security key. Teams link their database to a central directory to run these two checks.
When an engineer tries to log in, the database asks the directory first. The directory checks the password and sends a prompt to the user's device. Once the user approves the prompt, the directory confirms the login succeeded. The database then matches the user to an internal role with set permissions.
Admins group users into roles like read-only, analyst, or admin inside the database. Each role holds rules that say which tables the user can read or write. If the user passes the two checks, the session gets all those permissions. This setup keeps outside attackers with stolen passwords out of your core systems.
Why login checks leave a gap during live sessions
A strong login check only protects the front door of your database. It proves who the user is at the start of the session. Once the session starts, the two factor check finishes its job completely. It does not watch or filter the commands the user runs next.
Most teams give engineers broad roles so they can fix production issues fast. An engineer with write permissions can update one row or drop a whole table. If an attacker steals an active session, they skip the login check entirely. Even a careful engineer can run a bad script that deletes customer rows.
Multi-Factor Authentication (MFA) + Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native database roles also return full rows of data to any allowed user. If a table holds emails, phone numbers, or card numbers, the query returns them. You have to build manual views for every table to hide those columns. Maintaining custom views across dozens of databases takes too much time for busy teams.
Adding command checks and data masking to active sessions
To close this gap, teams need controls that work after the login step. Instead of trusting a whole session, you should check each query before it runs. This approach lets an engineer log in with minimal permissions by default. When they need to run a risky write command, they request quick approval.
A peer can review the exact command and approve it in their chat app. You can also apply data masking rules to the results of any query. Masking rewrites matched fields like emails, phone numbers, and national IDs in results. This keeps sensitive data safe during everyday work while keeping login checks strong.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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
What are the two factors in a two factor model?
The first factor is something you know, like a password or a PIN. The second factor is something you have, like a phone app or hardware key.
Does two factor login stop bad database queries?
No, it only checks who logs in at the start of a session. Once logged in, the user can run any query their database role allows.
How can teams protect sensitive columns after login?
Teams use dynamic data masking to rewrite matched fields in query results. This hides card numbers, phone numbers, and emails without changing the database tables.