The application uses confidential or device-specific information to create a unique identifier. The value of this ID is preserved after formatting the device or reset to factory defaults. It is not recommended to use the device ID for login and user authentication. Moreover, the device identifier leak can damage users’ confidentiality.

Insecure Authentication vulnerabilities take the fourth place in the “OWASP Mobile Top 10 2016” mobile application vulnerabilities ranking.

The most straightforward solution to identifying an application instance running on a device is to use an Instance ID, and this is the recommended solution in the majority of non-ads use-cases. Only the app instance for which it was provisioned can access this identifier, and it’s (relatively) easily resettable because it only persists as long as the app is installed.

As a result, Instance IDs provide better privacy properties compared to non-resettable, device-scoped hardware IDs. They also come with a key-pair for message signing

In cases where an Instance ID isn’t practical, custom globally unique IDs (GUIDs) can also be used to uniquely identify an app instance. The simplest way to do so is by generating your own GUID using the following code.

    String uniqueID = UUID.randomUUID().toString();

Because the identifier is globally unique, it can be used to identify a specific app instance. To avoid concerns related to linking the identifier across applications, GUIDs should be stored in internal storage rather than external (shared) storage.

Android : Insufficient database access control (SQLite)

DerScanner Severity Score

Do you want to fix Android : Insufficient database access control (SQLite) in your application?

See also