Skip to main content
Login is a hot path. A real user will hit it dozens of times a month, so your error budget for false positives is small. The right pattern is a narrow action-time check at password submit — not a page-load probe — paired with a step-up challenge on inconclusive rather than a block.

​
The threat

Credential-stuffing tools replay dumps of leaked email:password pairs against login endpoints at high volume. The goal is account takeover: any hit becomes a compromised account. Unlike signup, the attacker isn’t trying to create new identity — they’re trying to prove that an existing identity is theirs. That changes the policy calculus. The pattern to detect is automated typing and submission: a headless browser driving a form fill, or an HTTP-level script bypassing the UI entirely. Tripwire’s automation attribution (Playwright/Puppeteer/Selenium) and ai-agent attribution (LLM-driven login) both land here. Two properties of the login surface shape the integration:
  • Users arrive hot. They click a link in an email, they open a bookmark, they come back from a timeout. Fingerprint readiness at page load is aspirational, not guaranteed.
  • False positives are expensive. Locking a human out of their own account is a worse user experience than letting a bot try three times against a non-matching password. The verdict is one input among several — Tripwire goes on one side of a scale that already has rate limiting and MFA on it.

​
The flow

1

Start Tripwire on page load

Collection begins. Don’t block the form on waitForFingerprint() — users arriving cold should still be able to submit.
2

Call getSession() at password submit

Not on page load. You want the freshest possible observation set, and you want collection to include the keystroke and mouse signals from the user typing their password.
3

Verify and fold into your auth decision

A bot verdict returns the same generic error as a wrong password. An inconclusive verdict with an otherwise-valid password triggers a step-up challenge.
4

Rate-limit by visitor fingerprint, not just IP

The verified token carries a visitor_fingerprint.id. Use it to apply per-device limits that survive residential-proxy IP rotation.

​
Client integration

Call getSession() lazily at password submit. Don’t await waitForFingerprint() — if fingerprinting has resolved by submit, great; if not, Tripwire still returns a session based on the snapshot and behavioral evidence it has. 
<script type="module">
  const tripwirePromise = import("https://cdn.tripwirejs.com/t.js").then(
    (Tripwire) =>
      Tripwire.start({
        publishableKey: "pk_live_your_publishable_key",
      }),
  );

  document.querySelector("#login-form").addEventListener("submit", async (e) => {
    e.preventDefault();
    const tripwire = await tripwirePromise;
    const { sessionId, sealedToken } = await tripwire.getSession();

    await fetch("/api/login", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        email: e.target.email.value,
        password: e.target.password.value,
        tripwire: { sessionId, sealedToken },
      }),
    });
  });
</script>

​
Server verification

const { safeVerifyTripwireToken } = require("@abxy/tripwire-server");

app.post("/api/login", async (req, res) => {
  const tripwireResult = safeVerifyTripwireToken(
    req.body.tripwire.sealedToken,
    process.env.TRIPWIRE_SECRET_KEY,
  );

  // Check the password regardless — don't skip the bcrypt compare.
  // A bot should not be able to use timing to distinguish states.
  const passwordMatches = await verifyPassword(req.body.email, req.body.password);

  if (!tripwireResult.ok || tripwireResult.data.decision.verdict === "bot") {
    // Generic error — same response shape as wrong password.
    return res.status(401).json({ error: "Invalid credentials" });
  }

  if (!passwordMatches) {
    return res.status(401).json({ error: "Invalid credentials" });
  }

  const verdict = tripwireResult.data.decision.verdict;
  const visitorId = tripwireResult.data.visitor_fingerprint?.id;

  if (verdict === "inconclusive") {
    // Password is correct, but we're not confident. Require a second factor.
    const challengeToken = await issueStepUpChallenge(req.body.email, visitorId);
    return res.json({ status: "step_up", challengeToken });
  }

  const session = await issueLoginSession(req.body.email);
  res.json({ status: "ok", session });
});

​
Decisioning policy

VerdictRecommended action on login
human + password matchesIssue a session.
human + password mismatchReturn generic Invalid credentials.
inconclusive + password matchesRequire a second factor (TOTP, email OTP, WebAuthn).
inconclusive + password mismatchReturn generic Invalid credentials.
botReturn generic Invalid credentials. Always.
Three things to get right:
  • Always check the password. Skipping the bcrypt compare on a bot verdict creates a timing oracle. Run the comparison, throw the result away if Tripwire blocks.
  • Return identical responses for bot-detected and password-mismatch. Status code, body shape, timing. Any difference is signal for an attacker automating against your endpoint.
  • Prefer step-up over block on inconclusive. If the password is correct and the verdict is ambiguous, a legitimate user can pass a TOTP prompt. A bot running on a dump of leaked credentials usually can’t.

​
Rate-limiting by visitor fingerprint

The verified token exposes visitor_fingerprint.id — a durable per-device identifier that survives cookie clears, incognito mode, and residential-proxy IP rotation. It’s the right key for login attempt counters.
Node.js
const redis = require("redis");
const { safeVerifyTripwireToken } = require("@abxy/tripwire-server");
const client = redis.createClient();

async function checkLoginRateLimit(tripwireToken) {
  const result = safeVerifyTripwireToken(tripwireToken, process.env.TRIPWIRE_SECRET_KEY);
  if (!result.ok) return { allowed: false, reason: "no_token" };

  const visitorId = result.data.visitor_fingerprint?.id;
  if (!visitorId) return { allowed: true };

  const key = `login_attempts:${visitorId}`;
  const attempts = await client.incr(key);
  if (attempts === 1) await client.expire(key, 3600); // 1h window

  if (attempts > 10) {
    return { allowed: false, reason: "rate_limited", visitorId };
  }
  return { allowed: true, visitorId };
}
This is complementary to IP-based rate limiting, not a replacement. Run both. IP counters catch volumetric attacks; fingerprint counters catch distributed attacks routed through rotating residential proxies where each request comes from a different IP but the underlying device is the same.
visitor_fingerprint is null on sessions where Tripwire couldn’t establish a durable ID (typically: hardened privacy browsers, very short sessions). Treat a missing visitor ID as “skip the fingerprint rate-limiter, rely on IP” rather than as a signal to block.

​
What’s next

Signup protection

Block automated account creation.

Server verification

Reference for the underlying verification primitive.

Going to production

Rollout plan and monitoring.

Verdicts & scoring

Understand what inconclusive actually means.