Insufficient Input/Output Validation

M5: Improper Credential Usage is a category that covers various types of flaws that allow attackers to access or misuse the credentials that are used by mobile applications to authenticate or authorize users or systems. Credentials are the information or data that prove your identity or authority, such as usernames, passwords, tokens, certificates, keys, etc. For example, when you use your email app to send or receive emails, you need to provide your username and password (credentials) to authenticate yourself to the email server.

Improper credential usage can happen when mobile applications do not handle or protect the credentials that they use or rely on in a secure way. For example, some common flaws are:

• Hardcoded credentials: Some applications store credentials in the code or configuration files of the app, which means that anyone who can access the app can see or extract the credentials in plain text or clear text. For example, an app that connects to a database might store the database username and password in the code of the app.

• Exposed credentials: Some applications expose credentials to other apps or systems that are not authorized or trusted. They might store credentials in insecure locations on the device (such as shared preferences or caches), transmit credentials over insecure channels (such as HTTP or SMS), or share credentials with third-party services (such as analytics or advertising) without proper consent or disclosure. For example, an app that uses a third-party service to send push notifications might share the user’s device ID and token with the service without asking for permission or informing the user.

• Reused credentials: Some applications reuse credentials for different purposes or systems that have different security levels or requirements. They might use the same credentials for multiple apps or services, use the same credentials for authentication and encryption, use the same credentials for different users or roles, etc. For example, an app that uses a social media account to log in might use the same username and password for encryption.

• Weak credentials: Some applications use credentials that are weak or easy to guess or crack by attackers. They might use credentials that are short, simple, common, predictable, or default, such as “123456” or “password”. For example, an app that uses a PIN code to lock the app might use a four-digit PIN code that is easy to brute-force.

These flaws can lead to serious consequences, such as data breach, account takeover, privilege escalation, fraud, etc. Therefore, it is very important for mobile applications to implement and enforce proper credential usage mechanisms, such as:

• Credential encryption: Applications should encrypt the credentials that they store on the device or the server side using secure and up-to-date encryption algorithms (such as AES or SHA) and keys (such as 256-bit or 512-bit). They should also encrypt the credentials that they transmit over the network using secure and up-to-date encryption protocols (such as HTTPS or TLS). For example, an app that connects to a database should encrypt the database username and password using AES-256 and store them in a secure database on the server side.

• Credential protection: Applications should protect the credentials from unauthorized access or use by other apps or systems using proper access control mechanisms (such as authentication or authorization), proper data retention policies (such as deletion or anonymization), proper data sharing policies (such as consent or disclosure), etc. For example, an app that uses a third-party service to send push notifications should ask for user permission and inform the user before sharing the user’s device ID and token with the service.

• Credential separation: Applications should separate credentials for different purposes or systems that have different security levels or requirements. They should use different credentials for different apps or services, use different credentials for authentication and encryption, use different credentials for different users or roles, etc. For example, an app that uses a social media account to log in should use a different username and password for encryption.

• Credential strength: Applications should use credentials that are strong and hard to guess or crack by attackers. They should use credentials that are long, complex, unique, and random. They should also enforce credential expiration, lockout, and change policies. For example, an app that uses a PIN code to lock the app should use a six-digit PIN code that is randomly generated and changed every month.

I hope this explanation helps you understand what M5: Improper Credential Usage is and why it is important. If you want to learn more about this category and how to prevent it, you can check out these resources:

• [M5-Improper Credential Usage | OWASP Foundation]: The official website of the OWASP Mobile Top 10 project. It contains detailed information about this category and links to other useful resources.

• [Mobile App Security: How To Secure Your Mobile App Credentials]: A blog post that provides an overview of the best practices for mobile app credential security.

• [Mobile App Security Testing | Cybrary]: A course that teaches you how to test and secure mobile applications against various security risks.