Castle's client-side libraries aim to collect device information in order to determine uniqueness of devices. This allows Castle to reliably identify devices for future events, as well as monitor user interactions for anomalies.
The fingerprinting allows detection of, for example, a single device being used to access or register for multiple accounts. It also allows Castle to detect attempts to falsify device information, which is frequently a sign of malicious intent. It is also required for generating a risk score.
The data collected by Castle's fingerprinting depends on the device being used. The reason for this variance is that different platforms expose different device properties. In general, the properties include things like screen resolutions, pixel density, video and audio capabilities, installed plugins, and any exposed hardware properties such as number of CPU cores.
Castle does not intentionally collect any sensitive or personal identifiable information, for instance no text strings are collected from the client.
When generating the fingerprint, we try to minimize the chance of "collisions", so that two different physical devices cannot be merged together to produce a single fingerprint. Because our risk models rely on so much more than just device fingerprints, we would rather miss a fingerprint sometimes than merge two separate devices by mistake. The reason behind this optimization is so your team will be able to confidently block or contact an individual seen using multiple accounts on the same device, without risking customer backlash due to a false positive.
In the case where two users buy the same computer and both install Google Chrome at the same time, even though their configurations are nearly identical, our device fingerprinting would see them as different devices after we account for other pieces of context, such as when, how, and from what location a new user account was created.
Despite clearing cookies and opening incognito windows in your browser, our device fingerprinting will continue to attempt to resolve to the same fingerprint, and on mobile devices, the fingerprints are designed to survive app uninstalls and memory wipes. Having said that, there will be times when we will prefer to create a new fingerprint rather than attempt to resolve an existing one, using the same optimization as described previously. This can happen when a fingerprint hasn't been seen for over a month, then returns after having reset the storage on their device or updated it to a new version, and then creates a brand new account. However, as long as the user logs into the same account that they have previously used, we will very likely resolve it to the same device.
Fingerprinting is available for the browser (Castle.js) and for various mobile application development platforms, including native iOS, native Android, React Native, and Flutter.
We strive to make our fingerprinting extremely lightweight and performant.
Our mobile SDK's offer configurable batch-processing settings. The packaged SDK sizes are provided on GitHub.
The fingerprinting data is represented by a variable called request token which is designed to be generated fresh before each server-side request to Castle's APIs. Tokens are meant to be used only once per server-side request and will expire after 120 seconds. If a request token generated for a specific device is copied and used for a different device, we apply spoof detection in order to detect such tampering.
Castle's mobile SDKs are open-source repositories on Castle's GitHub account. We welcome the creation of issues and pull requests from the community.
Updated 4 months ago