In a previous article, 9 Device Fingerprinting Solutions for Developers, I outlined a set of open source and commercial solutions for device fingerprinting. What I didn't dig into in that article is how the fingerprints are actually used in preventing fraud.
One misconception is that a fingerprint alone is a way of stopping fraud, but the reality is that most vendors don't really expose a global reputation for the device. Instead, what I’ve found in exploring existing security solutions on the market, is you'll have to build features using the fingerprints, preferably in a way that can aggregate features in real time so that they can actually be used for blocking. It's rather similar to what was required before the era of device fingerprinting, but you would instead use an IP address or user agent to do the aggregations.
The device fingerprinting functionality at Castle was inspired by a need for a more dynamic way to aggregate features in real time. Below are 7 rules you can use to prevent fraud by doing live feature aggregation. Castle, which is a flexible fraud prevention platform, allows you to build any custom feature aggregators including the ones mentioned here. Since SQL tends to be quite long for aggregations, I’ve added pseudo-code to each rule as a shortcut which should hopefully be self-explanatory.
The 7 Rules
Rule 1: Multiple signups per device fingerprint
Perhaps the most common form of fraud is creating multiple accounts using the same device, often for the purpose of taking advantage of promotions, evading bans, or engaging in identity spoofing. Counter such attempts by tracking and limiting signups associated with a specific device fingerprint. Implement this technique by storing each device fingerprint and its corresponding signup count in your database. When a new account is created, check for the existing device fingerprint and the incremental signup count accordingly.
{
aggregations: {
signupsPerDevice: {
select: 'countEvents()',
where: 'event = "Signup"',
groupBy: 'device.fingerprint',
window: '180d'
}
},
where: 'signupsPerDevice > 3'
}Rule 2: Multiple Logins from New Device Fingerprints
Similar to Rule 1, count the number of logins per device, but only count each login once per unique account, and additionally, only count it when the device is new to the account, filtering out normal logins. This rule is designed to detect a malicious actor iterating through a set of accounts using stolen credentials, and each time they log into a new account the counter will increase incrementally. We'll keep a pretty tight time window in order to not include logins from regular users logging into multiple accounts from time to time.
{
aggregations: {
uniqueLoginsPerDevice: {
select: 'countUnique(user.id)',
where: 'event = "Login"',
groupBy: 'device.fingerprint',
window: '4h'
}
},
where: 'uniqueLoginsPerDevice > 3'
}Rule 3: Excessive Flip-Flopping of Fingerprints in the Same Account
By counting the number of times a device fingerprint changes between events within an hour, you can identify instances of account sharing. This rule requires tracking events mid-session, not just logins, such as page views or frequent actions like posting messages. At Castle, we solve this by providing a JavaScript agent that seamlessly tracks any page the user visits.
{
aggregations: {
lastDeviceFingerprint: {
select: 'last(device.fingerprint)',
groupBy: 'user.id',
window: '1h'
},
flipFlops: {
select: 'countEvents()',
where: 'lastDeviceFingerprint != device.fingerprint',
groupBy: 'user.id',
window: '1h'
}
},
where: 'flipFlops > 10'
}If you want to be more advanced, you can add another condition to include "device type", in order to allow one mobile and one desktop device active at the same time. This would be done by changing groupBy to ['user.id', 'device.type'].
Rule 4: Session Hijacking
Session identifiers are often at risk of being stolen if the user is subject to malware or a malicious browser extension. By counting the number of fingerprints per session ID over a relatively short time window, any time there's more than one, it's an indication of a session hijack.
{
aggregations: {
devicesPerSession: {
select: 'countUnique(device.fingerprint)',
groupBy: 'session.id',
window: '4h'
}
},
where: 'devicesPerSession > 1'
}Rule 5: Rapid Signup
Legitimate users often take their time to read up on what your site offers before creating an account. A fraudster, however, will go straight through the signup flow. Implement a ping endpoint that is called every time a visitor lands on your site, saving the timestamp of the fingerprint, which can then be checked at the point of signup.
{
aggregations: {
firstDeviceTime: {
select: 'first(timestamp)',
groupBy: 'device.fingerprint',
window: '30d'
}
},
where: 'event = "Signup" and firstDeviceTime < 30.seconds.ago'
}Rule 6: Excessive Events per Device Fingerprint
Apply rate limiting to fingerprints to eliminate automated bot traffic or bad actors speed-clicking through your site. Over time, you may want to be more specific and limit certain business actions, but a catch-all approach serves as a good starting point.
{
aggregations: {
eventsPerDevice: {
select: 'countEvents()',
groupBy: 'device.fingerprint',
window: '1h'
}
},
where: 'eventsPerDevice > 50'
}Rule 7: Trusted Device Fingerprints
Lastly, there is a technique that doesn't involve feature aggregation, but rather a handy way of reducing friction in general. Allow users to verify access by completing a 2FA challenge or identity verification, marking the fingerprint as trusted for a limited period of time, such as 14 or 30 days. This reduces friction for legitimate users, allowing for stricter security measures overall.
Putting it all Together
Often simply looking at data aggregated on the fingerprint isn't enough, but it’s also important to look out for things like the email format, whether the user is on a proxy IP, or other in-app behaviors such as completing otherwise slow actions in rapid succession. Additionally, it's often not even enough to use just a single rule out of these seven, but what you can instead do is to feed the output values of all the rules into a scoring engine and output a confidence between 0 and 100%. Or better yet, you can have Castle do it for you! If these are things you're looking to implement, don't hesitate to reach out to us at Castle and we'll get you sorted.