Stop account takeover with device signals, not more passwords.

Account takeover prevention works best when your login can tell the customer from someone who merely has the customer’s password. Device recognition at login does exactly that: remember the devices each account uses, let them through with little friction, and challenge the sign-ins that arrive from somewhere new or suspicious.

This playbook walks through how to do that with Fingerly: which moments to check, how to read the result on your server, a starting policy, and how to avoid locking out the customers you are protecting.

#What is account takeover, and why does a password not stop it?

In an account takeover, someone other than the customer gets into their account, usually with a password stolen from another site, phished, or reset through a hijacked email address. To your login form the attacker looks exactly like the customer: the right email and the right password.

What differs is the device. The customer signs in from the laptop and phone they always use. The attacker arrives from a device the account has never seen, often through a script, a proxy or a modified browser. That difference is evidence your password check cannot see.

#How does device recognition at login work?

You keep a list of known devices for each account and compare every sign-in with it. Fingerly returns a visitor ID for the device behind each identification, stable across cleared cookies, private windows and network changes. Your server stores the IDs an account has successfully signed in from, and treats a device on that list as familiar.

• Identify at login with a tag such as login, and send the request ID with the credentials.
• Read the stored event on your server with a secret key and run the four checks: it exists, it is for this action, it is recent, and it passes your policy.
• Check the password first, as you do today. Only for a correct password, decide what the device means.
• Add a device to the account’s list only after a sign-in that fully succeeded, including any second factor. Otherwise an attacker’s failed attempt would make their device known.
• Keep a last-seen date with each device, and forget devices not seen for a few months.

#Which moments need a check?

Check every step where an attacker turns a stolen password into control or money, not only the login form.

• Login, where a stolen password is first used.
• Password reset requests, because many takeovers start with a reset from a device the account has never used.
• Changing the email, phone number or second factor, which attackers do to lock the owner out before they act.
• Payouts, withdrawals and new payees, where a takeover becomes a loss.

#What does a starting policy look like?

Let known devices through with little friction and scale the challenge with the suspect level for new ones. The Fingerly docs suggest this starting point, which you should tune on your own traffic:

• Low level, known device: allow. Low level, new device: allow, and tell the customer about a sign-in from a new device.
• Medium level or unscored, known device: allow. New device: ask for a second factor.
• High level, known device: ask for a second factor. New device: refuse the attempt without saying why, and tell the customer.
• No usable identification: ask for a second factor.

Use the same table for resets, account changes and payouts with their own tags. For payouts, consider treating a medium level on a new device as high. A known device lowers friction; it is never a reason to skip the password.

#Which signals add context to a login?

Network and device signals turn a new device from a question mark into a decision. A login from a Tor exit or a datacenter proxy, on a device the account has never used, is worth a second factor. The same login from a phone on mobile data is not. Attackers also tend to hide where they are, rotate addresses to get past per-address limits, and automate the attempts.

• Network: Tor exit nodes, datacenter and residential proxies, commercial VPNs, hosting networks, addresses with a history of abuse, and a location that disagrees with the device.
• Browser: automation, virtual machines, and modified or anti-detect browsers.
• Apps: emulators and simulators, rooted and jailbroken devices, and instrumentation attached to the app.

Each signal has a default weight per platform that you can change, and a weight of zero still records that the signal fired. To make one decisive for logins, read it from the event’s triggers or raise its weight.

#How do you avoid locking out real customers?

Challenge in proportion, explain nothing to attackers, and tell the real owner. Customers change phones and browsers, travel, and use hardened browsers. A device whose browser hides almost everything gets no stable recognition and is reported as unidentifiable, so those customers are asked for a second factor rather than refused.

• Observe before you enforce: log what the policy would have done for a week or two.
• Send a notification when a new device signs in, so a real owner can react.
• Offer a recovery path, such as email verification or support, to anyone who is challenged.
• If identification fails, carry on and decide with less information. Detection fails open, and your policy can still require a second factor for any request that arrives without a score.