Building resilient authentication: device recognition beyond passwords

Passwords are the weak point of most sign-in systems: people reuse them, attackers collect them from breaches, and once one leaks, it works for anyone. Multi-factor authentication fixes much of this, but adds friction to every sign-in.

Device recognition helps you spend that friction only where it's needed. A sign-in with the right password from the browser this account always uses is a different risk from the same password on a browser it has never used.

Recognizing the device at sign-in

Identify the browser on your sign-in page and send the visitor ID with the credentials:

import { TraceTail } from '@tracetail/js';

const tracetail = new TraceTail({ apiKey: 'YOUR_API_KEY', endpoint: 'https://tracetail.io/api' });
const { visitorId } = await tracetail.generateFingerprint();

// Send the visitor ID with the sign-in request.
await fetch('/api/login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email, password, visitorId }),
});

On the server, check the credentials first, then the device:

async function signIn({ email, password, visitorId }) {
  const user = await verifyCredentials(email, password);
  if (!user) return { error: 'invalid_credentials' };

  const knownDevice = await db.userDevices.findOne({ userId: user.id, visitorId });
  if (knownDevice) {
    await db.userDevices.update(knownDevice.id, { lastSeenAt: new Date() });
    return { ok: true };
  }

  // A browser this account hasn't used: ask for a second factor first.
  return { ok: true, requireSecondFactor: true, reason: 'new_device' };
}

Risk-based decisions

Not every sign-in needs the same scrutiny:

• Known device, familiar network, usual hours: let them in.
• Known device, new network: they may be traveling; allow it and note it.
• New device, familiar network: possibly a new laptop; ask for a second factor once, then remember the device.
• New device, new network, odd hours, recent failed attempts: ask for a second factor and tell the account owner by email.

function signInRequirements({ knownDevice, knownNetwork, unusualHour, recentFailures }) {
  let score = 0;
  if (!knownDevice) score += 40;
  if (!knownNetwork) score += 20;
  if (unusualHour) score += 15;
  if (recentFailures > 0) score += 25;

  if (score < 20) return { secondFactor: false };
  if (score < 60) return { secondFactor: true };
  return { secondFactor: true, notifyOwner: true };
}

Check again at sensitive moments

A session can be hijacked after sign-in. Rather than polling, identify the device again when it matters, for example before a password change, a payout or new payment details, and compare it with the device that signed in:

const { visitorId } = await tracetail.generateFingerprint({ refresh: true });

A mismatch is a reason to ask for the password or a second factor again.

Where the signal stops

• It's evidence, not proof. The visitor ID is computed in the visitor's browser and sent by your own page, so treat it as a strong signal rather than proof: an attacker who controls their browser can send any ID they like, including one they learned from a victim. Use it to decide when to ask for a second factor, never as the only factor.
• Devices change. The visitor ID uses the browser family, not its version, so routine browser updates don't change it. A new GPU driver or a major operating system update can, though. Treat that like a new device: verify once, then remember it.
• People share devices. Two family members on one laptop share a visitor ID; your account logic, not the device check, keeps them apart.

What users see

For most sign-ins on recognized devices, nothing changes: a password, a passkey or single sign-on, and they're in. Only when something is unusual do they see an extra step, and you can tell them why: "We don't recognize this device. Enter the code we sent you."

That's better security without extra work on routine sign-ins.

Getting started

Add the SDK to your sign-in page, pass the visitor ID to your backend, and build the rules above on your side. The free allowance of 1,000 requests a month is enough to try it end to end. Read the docs.