Looker Two Factor Authentication
You set up looker two factor authentication in the admin panel or an identity tool. This rule makes every user enter a temporary phone code when they log in. Most teams turn on this check to stop stolen passwords from opening business reports. Still, a strong login check does not limit what broad user roles can read. Once a user logs in, wide role rules still expose raw database tables. How looker two factor authentication works in practice Teams can turn on a second login step right inside t
Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up looker two factor authentication in the admin panel or an identity tool. This rule makes every user enter a temporary phone code when they log in. Most teams turn on this check to stop stolen passwords from opening business reports. Still, a strong login check does not limit what broad user roles can read. Once a user logs in, wide role rules still expose raw database tables.
How looker two factor authentication works in practice
Teams can turn on a second login step right inside the reporting app. When an admin flips this switch, each user must pair a mobile phone app. On the next login, the screen shows a barcode for the user to scan. The phone app then makes a fresh numeric code every few seconds. The user types both their password and this short code to open their account.
Many companies prefer to handle logins through a central identity provider instead. They link the reporting tool to their main corporate login system using standard protocols. In this setup, the identity provider runs the second factor check during sign-in. The reporting app trusts the identity system and lets the user in right away. This method keeps all login rules and user lists in one single place.
Admins can also force new device checks when users switch laptops or browsers. If a session expires, the person must prove who they are all over again. If someone loses a phone, an admin can reset their secret key fast. This workflow keeps outside attackers from using leaked passwords to read company charts.
Why login checks leave database queries exposed
A second login factor solves one big problem for analytics and data teams. It proves that the person at the keyboard owns the account they use. This stops basic phishing tricks and credential stuffing attacks at the front door. Auditors require this step because passwords alone are too easy to steal or guess.
Still, login checks only decide who gets into the app at the start. They do not check the SQL queries that run after the session begins. The reporting app still talks to the database using a shared service account. That backend account often holds wide read permissions across many sensitive schemas and tables.
Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If an analyst has broad role settings, they can query raw customer records. They might run custom queries that pull emails, phone numbers, or card numbers. A two factor check cannot tell a safe chart from a bulk data export. It also cannot rewrite sensitive columns in query results before they reach the screen.
Managing shared database credentials behind analytics tools
Analytics apps need a steady link to your data warehouse to build dashboards. Most teams put a single database user and password into the app settings. Every chart and custom query runs through that one powerful database identity. When you look at database logs, every query comes from the same app user.
This setup makes it hard to see which person ran a heavy query. It also means you cannot pause a risky query for quick human approval. Rotating that shared database password takes careful coordination so dashboards do not break. Security teams need controls that inspect actual queries and mask data in flight.
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
Should we use built-in two factor checks or an identity provider?
Use an identity provider if your company already manages logins in one central place. Built-in checks work well for smaller teams without a single sign-on system.
What happens when a user gets a new phone?
An admin must clear the old key in the user settings panel. The user then scans a fresh barcode on their next login attempt.
Does two factor login protect raw database credentials?
No, it only checks the human user at the login screen. The reporting app still stores and uses its own backend database keys to run queries.