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.

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 browser and is stored in a dedicated non-extractable way on the device. The key format is the same for Web, iOS, and Android devices.

• Web : IndexDB
• Android Keystore
• iOS : Keychain

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 get 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.

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.

To report data and actions:

1. 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.
2. Report all actions that are relevant to your use case using the triggerActionEvent() call. For example, report login , password_reset , and all other relevant actions .
3. 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.
4. When a user logs out or a user session expires, make sure you call clearUser() so they are not associated with future actions.

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.