Understanding setRMDeviceId() and getRMDeviceId() in DeviceDNA SDK

Products

• CA Advanced Authentication - Strong Authentication (AuthMinder / WebFort)
• CA Advanced Authentication - Risk Authentication (RiskMinder / RiskFort)

Issue/Introduction

When using Advanced Authentication DeviceDNA SDK, customers often have questions regarding the use of device identifiers and how mutable they are across different scenarios such as app re-installation, OS updates, or factory resets. This article addresses the behavior of getRMDeviceId() and setRMDeviceId() and compares the SDK's behavior with OS-level device identifiers.

Environment

Advanced Authentication DeviceDNA SDK

Resolution

• What happens to the device ID after an app uninstall/re-install?

  • When a user uninstalls an app that utilizes the Mobile OTP library (which calls getRMDeviceId()) and then reinstalls it, the behavior of the DeviceDNA SDK depends on how the device ID is stored.
  • On iOS, the SDK uses CFUUID stored in the keychain, which persists even after the app is uninstalled. Upon reinstallation, the SDK accesses the same CFUUID unless the user explicitly deletes it or there is a keychain access group change.

• What happens to the device ID after an OS or security update?

  • OS updates generally do not impact the persistence of device identifiers like CFUUID on iOS or Secure.ANDROID_ID on Android, as long as no factory reset is performed.
  • However, keychain access may be lost on iOS if there are changes in the app’s access group identifier, which happens after an app update with a new App ID. Similarly, Secure.ANDROID_ID will change if a factory reset is performed on Android devices.

• When can the device ID change?

  • The device ID can change in the following scenarios:
    • iOS: If the CFUUID is explicitly deleted by the user from the keychain or the keychain access group identifier changes (due to changes in App ID).
    • Android: The Secure.ANDROID_ID can change if a factory reset is performed.
    • Windows Phone: The PublisherHostId changes when the last app from the same publisher is uninstalled.

Key SDK Methods:

• getRMDeviceId(): This method retrieves the device ID that uniquely identifies a device within the scope of the application. The SDK typically relies on OS-provided identifiers like CFUUID (iOS) or Secure.ANDROID_ID (Android).

• setRMDeviceId(): You can customize the device locking mechanism by implementing the DeviceLock interface and calling the setDeviceLock() method to lock an account using custom device parameters instead of default device IDs.

Best Practices for Reliable Device Identification:

• For scenarios where a consistent device ID across the device's lifecycle is critical, OS-level identifiers like CFUUID (iOS), Secure.ANDROID_ID (Android), or PublisherHostId (Windows Phone) are preferred over the SDK's default behavior.
• Ensure the app does not change its keychain access group identifier on iOS to maintain access to the device ID after an app update.
• Understand that factory resets on Android will change Secure.ANDROID_ID, which may impact device ID continuity.

 

Additional Information

Additional Considerations:

• For Huawei devices, the behavior is generally similar to Android devices in the context of Secure.ANDROID_ID.
• Developers can implement custom device-locking mechanisms using setDeviceLock() for more flexibility, especially when default identifiers are insufficient.

Solution/Recommendation: For persistent and reliable device identification, using OS-integrated options like CFUUID, Secure.ANDROID_ID, or PublisherHostId is recommended for the best consistency across app uninstall/re-install scenarios and OS updates. Additionally, you can customize the behavior with the setRMDeviceId() method to lock accounts based on custom parameters.