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 Fraud Prevention collects various telemetry data, including device identifiers (device ID, device fingerprint, device key ID) and takes 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.
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.
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.
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 alphanumeric 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.
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 bad actors to guess it and gain unauthorized access.
Device private-public key pair is 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 uninstalled 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
Mosaic does not expose the exact public key in the Admin Portal or via APIs but operates with its key–a unique identifier derived from the device’s cryptographic identity (for simplicity called a device key ID). This identifier remains consistent even when the underlying cryptographic keys rotate (90 days). This ensures stable device identification over time while being abstracted from user identity.
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 key ID |
|---|---|---|---|
| Accurate identification | Yes | No | Yes |
| Resilience to replay attacks and cookie hijacking | No | Yes | Yes |
| Robust to data wipe | No | Yes | No |
Given the complexity of today’s threat landscape and the limitations of standalone methods, organizations should not rely on any single device identification technique.
- Device key ID is the most robust option, offering cryptographic proof of device ownership, resistance to interception, and support across web, iOS, and Android.
- Device ID remains useful for linking sessions and spotting reused tokens in credential-stuffing or bot attacks, but is more susceptible to hijacking or clearing.
- Device fingerprinting provides resilience when client-side anchors are unavailable (e.g., private browsing, cleared storage, or device resets).
Device identity plays integral part in building a thorough risk profile. The recommendation takes into account various risk data, including device identifiers (device key ID, device ID, and device fingerprint). 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 ID should not be trusted.
For example, this is how you can verify device identity and recognize a returning device by incorporating device identifier assessment into your app business logic:
➊ Check a device key ID:
- If the device key ID is recognized for a user and has no risk associated with it, proceed further.
- If the device key ID is recognized for a user but is known as fraudulent, deny access. Consider blocking the device by its device key ID 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 identify the user and recognize this device as returning in the future. See Register device journey step for details.