M1: Improper Credential Usage

A new addition to the 2024 list, this refers to the hard coding of credentials within source code, as well as to the handling of any credentials entered by the user.

This potential weakness can be exploited by various means, including automated attacks. Once credentials have been obtained, a threat agent can gain unauthorised access to the app, including potentially sensitive functionality and data.

Although this is reported as a common occurrence, the good news is that it’s easy to detect, and if you’re following best practice you”ll already be protected against it.

The first potential cause is listed as “Hard coded credentials”. If your source code contains any credentials, these can potentially be extracted without too much fuss and used by a threat agent. Although it could be argued that implementing a mitigation for M7: Insufficient Binary Protection affords some protection here, decompiling an app’s binary is not the only method to get at its source code. Weaknesses outside of the mobile space may have left your source repository vulnerable.

The next listed cause is “Insecure credential storage”. if a threat agent gains access to a device, stored credentials could be accessed. One solution to this is to ensure that credentials are securely encrypted proper to storage (ref. M10: Insufficient Cryptography). However, the best solution , and best practice for some time now, is to only store authentication tokens on the device, and never the actual credentials. Although outside the mobile arena, it’s interesting to look at the relatively recent Medibank data breach here in Australia, and the now accepted and documented cause. An employee of an organisation contracted to Medibank accessed their password protected resources using a browser on a work PC, and allowed the credentials to be stored by the browser. First bad idea. What took it from bad to worse was that the browser was connected to a personal profile on that work PC, meaning that when the employee next used their personal PC, linked to the same browser profile, those credentials were sync’d, and brought down. This PC was infected with malware, which allowed attackers to get hold of those credentials. Although there were several, let’s call them “missteps”, made by the employee, blame has been levelled at the organisation for not following best practice. If they had implemented multi-factor authentication, for example, the breach could have been thwarted before it occurred.

The final weak point discussed is “Weak user authentication”. Not following best practice for authentication, or trying to “roll your own” authentication, can leave you at risk of this.

In short, the best approach is to outsource your authentication to a trusted authentication provider. This can include Auth0, Microsoft, Google, Apple and others. However, the provider should be selected carefully, noting that, depending on your app’s scenario, it’s not necessarily a good idea to implement Facebook authentication (ref. M2: Inadequate Supply Chain Security).