Secure device identity
User devices are tightly connected to user identities. Ability to confidently identify devices not only reduces operational friction but is also crucial for fraud detection as imposers can mimic legitimate user devices in an attempt to take over their accounts.
Mosaic's detection and response services collect various telemetry data, including device identifiers (device ID, device fingerprint, device public key) and take them into account when assessing risk. This article describes how each device identifier contributes to an app's security posture and how to leverage them in your fraud analytics.
How it happens
Common attack vectors for device spoofing include:
- wiping out device identifiers to appear like a new device, and hiding from a bad device reputation
- hijacking cookies to gain access to device ID, and pretending to be a legitimate device
- mimicking the configuration of the known device
How device identifiers work
Device identifiers serve different roles in the context of identity tracking and risk assessment and all contribute to fraud detection. Mosaic recommends leveraging several device identifiers when you need to prove device ownership and secure device identity.
Note
In the context of web applications, the device represents a browser rather than a physical device like a smartphone or laptop your customer uses to access your application.
Device ID
A device ID is an opaque string that uniquely identifies a user's device to the apps. Depending on the platform, a device ID is generated by the vendor and stored by the browser or device itself.
- Web : Stored in JWT Cookie in the browser.
- Android : Android ID is a 64-bit number (expressed as a hexadecimal string).
- iOS : identifierForVendor is an alphanumberic string.
The device ID doesn't change over time and remains the same unless the device is reset, app uninstalled, or cookies cleared. Since a device ID can only be associated with a single device, it allows pinpointing actions such as logins to specific devices, attributing these devices as trusted or malicious. Device IDs stored as a cookie are vulnerable to replay attacks and cookie hijacking, i.e., when a fraudster steals the cookie and uses an emulator that spoofs the device ID.
Device fingerprint
A device fingerprint is a device identifier calculated based on a combination of device attributes configured by the user, and on how the device is used. Common attributes include screen resolution, browser type and version, time zone settings, IP address, operating system, GPU, etc. Mosaic stores a hashed value of the device fingerprint and its format is the same across Web, iOS, and Android platforms.
The device fingerprint can be used to identify the device, such as for recognizing trusted devices, detecting credential stuffing attacks and other spoofing scams. Since a device fingerprint is based on various attributes collected from the browser and hardware, the fingerprint remains consistent over time, it cannot be erased or reset like a device ID. Device fingerprints may have a small chance of collisions between different devices as browser and operation system vendors try to avoid unique fingerprints due to privacy concerns. It means there is still a small probability of a malicious actor successfully guessing all the right attributes to compromise the device fingerprint.
Fingerprints generated by Mosaic demonstrate an exceptionally low false acceptance rate (FAR) while keeping the false rejection rate (FRR) to a minimum. It means the device fingerprint remains consistent over time to allow recognizing known devices while being complex enough for badactors to guess it and gain unauthorized access.
Device public key (device crypto keys)
Device private-public key pair is a device identifier created on the user's device by Mosaic using cryptographic binding technology (Web Crypto API). The device public key is exported and sent to Mosaic while the private key never leaves the device and is stored in a dedicated non-extractable way on the device. The key format is the same for Web, iOS, and Android devices.
The cryptographic binding helps establish a strong association between the device and the keys. When the user attempts to authenticate or perform sensitive operations, the device uses its private key to sign the request, ensuring the authenticity of the events. The signed data is returned to Mosaic for verification, confirming that the request originated from a trusted device. This provides proof of device ownership with zero chance of collisions, and also prevents replay and man-in-the-middle attacks. Nonetheless, the crypto key could be removed in case of device reset which leads to inability to recognize a device as previously used. If an app gets unistalled and reinstalled, different platforms handle this as follows:
- Web : Crypto keys remain the same (there is no concept of uninstallation)
- Android : Crypto keys are new after uninstall & reinstall
- iOS : Crypto keys remain the same
Compare identifiers
For thorough risk assessment and fraud prevention, one has to follow a multi-layer approach and take all device identifiers into account as individually they don't provide a sufficient level of security.
Feature | Device ID | Device fingerprint | Device crypto keys |
---|---|---|---|
Accurate identification | Yes | No | Yes |
Resilience to replay attacks and cookie hijacking | No | Yes | Yes |
Robust to data wipe | No | Yes | No |
Step 1: Integrate DRS
The first step to securing device identity and detecting malicious devices is to provide Mosaic with the telemetry required to continuously assess risk for the given context, and to identify trusted users and their devices. Report sensitive actions as the user requests to perform them during risk moments.
Note
In the steps below, you’ll find references to API calls explained in the Quick Starts. Be sure to select the Quick Start that best fits your environment for full integration steps and code snippets.
To report data and actions:
- Add the Detection and Response code snippets, ideally on each page of your website. This will automatically provide telemetry to our machine learning engine—such as device, network, and other context data used to continuously assess risk.
-
Report
all
actions that are relevant to your use case using the
triggerActionEvent()
call. For example, reportlogin
,password_reset
, and all other relevant actions . -
Report action result and set the user in case of successful authentication for all subsequent events of the session. This will also be used to create and update a behavioral profile of the user, so we can detect anomalies in the future. The user can either be set using the
initialize()
call, or using Report action result API . In both cases, it should be set only after you've fully authenticated the user (including, for example, any 2FA that was required). Make sure the user identifier you use doesn't contain any personal information. -
When a user logs out or a user session expires, make sure you call
clearUser()
so they are not associated with future actions.
Details
Once you complete this step, you can already see how it works by running your app, requesting to perform a sensitive action that your snippet reports, and then going to the Admin Portal to see the recommendations associated with the action. In the next steps, you'll learn how to fetch recommendations yourself and act on them.
Step 2: Get recommendations
For every action you report, use our Recommendation API to fetch our recommendation. Recommendations automatically appear in the Admin Portal (Detection and Response > Recommendations). The recommendation takes into account various risk data, including device identifiers (device public key, device ID, and device fingerprint).
Step 3: Investigate
To gain a better understanding of device usage, proceed to the Investigation mode by selecting a recommendation from the list and clicking Investigate. In the Entity analysis tab, select Device and review data to gain insights into device activity. Learn about the actions and user IDs associated with the device identifier, IP addresses, and previous recommedations and reasons.
For example,
- For a legitimate user, a new device may not show historical activity but the fingerprint should be "clean" (won't have a fraud association or indicators of being shared by many other users or networks).
- On the contrary, a fingerprint that suffers from bad reputation may be an indicator that the device key should not be trusted. In such cases, Mosaic will usually recommends to "Challenge" the request.
Step 4: Mitigate risks
Based on the recommendation we provide, you can determine the risk level of the action in the given context, choose an appropriate risk mitigation strategy if needed, and build trust for the user, device, and network.
For example,
- Label an action ID associated with suspicious device to temporarily adjust Mosaic recommendations.
- For known malicious devices, create a rule to deny any activity aassociated with a device ID or public key. Mosaic doesn't recommend blocking devices by fingerprints as there is a tiny chance that by trying to block a fraudster, you might block a legitimate customer as well.
- If suspecting device spoofing by cookie hijacking (when a device ID matches several fingerprints), add the recommendation to your to-do list for further review and consider contacting a device owner to prevent their account takeover in your service. Alternatively, enforce step-up authentication for a compromised device.
You can also send the recommendations to your analytics systems for further persistancy and offline analytics.
Example
For example, this is how you can recognize a returning user's device by incorporating device identifier assessment into your app business logic:
➊ Check a device public key:
- If the device public key is recognized for a user and has no risk associated with it, proceed further.
- If the key is recognized for a user but is known as fraudulent, deny access. Consider blocking the device by its device public key or creating a rule .
- If the key is new, check a device fingerprint.
➋ Check a device fingerprint:
- If the device fingerprint is recognized for a user and has no risk associated with it, proceed further.
- If the fingerprint is recognized for a user but appears suspicious, challenge the user to avoid denying by fingerprint collision. If step-up authentication is successful, you can label this action as legit to improve risk assessment.
- If the fingerprint is new and other data looks good, proceed to device binding flow that will help you idenitfy the user and recognize this device as returning in the future. See Register device orchestration step for details.