M01: Improper Credential Usage - Overview

Table of Contents

• What is Improper Credential Usage?
• Why Does This Matter?
• Technical Context
• Real-World Impact
• Prevalence and Statistics
• Common Misunderstandings

What is Improper Credential Usage?

Improper Credential Usage occurs when mobile applications store, transmit, or use authentication credentials (passwords, API keys, tokens, certificates) insecurely. This includes hardcoding credentials in source code, storing them in plain text, or exposing them through logs and error messages.

Mobile applications often require credentials for various purposes:

• API authentication tokens
• Database connection strings
• Third-party service keys
• User passwords and PINs
• OAuth tokens and refresh tokens
• Encryption keys

Core Concept

Unlike traditional web applications, mobile apps are distributed binaries that run on potentially compromised devices. This creates unique challenges:

``

Mobile App Binary → Installed on User Device → Potentially Reverse Engineered

↓

Contains Hardcoded API Keys → Extracted by Attacker → Used to Access Backend

↓

Backend Systems Compromised

``

Key Vulnerability Points

1. Hardcoded Credentials: Embedding secrets directly in application code
2. Insecure Local Storage: Storing credentials in plain text on device
3. Logging Sensitive Data: Writing credentials to application logs
4. Transmission Issues: Sending credentials over insecure channels
5. Backup Exposure: Including credentials in device backups

Why Does This Matter?

The Business Impact

• Data Breaches: Exposed credentials lead to unauthorized backend access
• Account Takeover: User credentials compromised through device access
• API Abuse: Leaked API keys used for fraud or resource exhaustion
• Financial Loss: Fraudulent transactions, service abuse costs
• Regulatory Penalties: GDPR, CCPA violations for credential mishandling
• Reputation Damage: Loss of user trust and brand value
• Service Disruption: Revoked credentials require emergency app updates

The Technical Impact

• Backend Compromise: Attackers gain access to server infrastructure
• Lateral Movement: Compromised credentials used across systems
• Data Exfiltration: Direct access to databases and storage
• Service Impersonation: Attackers act as legitimate application
• Privilege Escalation: Access to admin or elevated functions

Technical Context

Mobile-Specific Challenges

Binary Distribution:

• Apps are distributed as compiled binaries
• Attackers can download and analyze APK/IPA files
• Reverse engineering tools are readily available
• String extraction is trivial

Device Storage:

• Multiple storage locations (SharedPreferences, files, databases)
• Device rooting/jailbreaking exposes all storage
• Backups may be unencrypted
• App data persists after uninstall

Platform Differences:

| Platform | Storage Mechanism | Risks |

|----------|------------------|-------|

| Android | SharedPreferences, Internal Storage, SQLite | Accessible on rooted devices, backup exposure |

| iOS | Keychain, UserDefaults, CoreData | Accessible on jailbroken devices, iCloud backup sync |

Attack Surface

1. Static Analysis: Decompiling app to find hardcoded secrets
2. Dynamic Analysis: Runtime inspection of memory and storage
3. Network Interception: Capturing credentials in transit
4. Backup Analysis: Extracting data from device backups
5. Log Analysis: Finding credentials in system or app logs

Real-World Impact

Case Study 1: Mobile Banking App

Incident: A popular banking app hardcoded an API key for their backend services. Impact:

• Attackers extracted the key through decompilation
• Used the key to bypass authentication checks
• Accessed customer account information
• Bank forced to rotate all API keys and release emergency update
• Affected: 5 million users

Cost: $15 million in incident response, regulatory fines, and customer compensation

Case Study 2: Ride-Sharing Application

Incident: App stored user credentials in plain text on device. Impact:

• Stolen devices revealed user passwords
• Attackers gained access to payment methods
• Fraudulent rides charged to compromised accounts
• Class-action lawsuit filed

Cost: $8 million settlement, complete redesign of authentication system

Case Study 3: Social Media Platform

Incident: OAuth tokens stored without encryption in app's shared preferences. Impact:

• Malware on devices extracted tokens
• Accounts compromised without password knowledge
• Spam and malicious content posted
• Platform integrity questioned

Cost: 2.3 million compromised accounts, $20 million in remediation

Prevalence and Statistics

Industry Research Findings

Verizon Mobile Security Index 2023:

• 43% of mobile apps contain hardcoded secrets
• 67% of apps store credentials insecurely
• Credential issues found in 81% of financial apps tested

OWASP Mobile Security Testing Guide:

• Average of 2.4 hardcoded secrets per application
• 58% of apps expose credentials in logs
• 71% of apps don't use platform keychain/keystore properly

Common Vulnerabilities:

• 56% - Hardcoded API keys
• 34% - Plain text password storage
• 28% - Credentials in logs
• 41% - Unencrypted token storage
• 23% - Credentials in version control

Common Misunderstandings

❌ Myth 1: "Obfuscation Protects Credentials"

Reality: Obfuscation is not encryption. Hardcoded credentials can still be extracted with reverse engineering tools, just with slightly more effort.

❌ Myth 2: "Only Android Apps Are Vulnerable"

Reality: iOS apps are equally vulnerable. While the App Store review process may catch some issues, IPA files can be analyzed just like APKs.

❌ Myth 3: "Environment Variables Are Secure"

Reality: Build-time environment variables end up compiled into the binary. They're not secure for sensitive credentials.

❌ Myth 4: "Users Won't Root/Jailbreak Their Devices"

Reality: According to research, 10-15% of Android devices are rooted, and 5-10% of iOS devices are jailbroken. That's millions of potentially vulnerable users.

❌ Myth 5: "Our App Isn't Important Enough to Target"

Reality: Automated tools scan thousands of apps daily looking for exposed credentials. Attacks are often opportunistic, not targeted.

The Mobile Security Difference

Why This Is Worse on Mobile

| Aspect | Web Applications | Mobile Applications |

|--------|-----------------|---------------------|

| Code Access | Server-side, not accessible | Binary distributed to users |

| Storage | Server-controlled | User device, potentially compromised |

| Updates | Instant deployment | User must download update |

| Control | Full control over environment | No control over user device |

| Analysis | Can't decompile backend | Easy to decompile app |

Defense Complexity

Mobile applications must defend against:

• Local attacks: Device access, reverse engineering
• Network attacks: Man-in-the-middle, interception
• Platform attacks: OS vulnerabilities, malware
• User behavior: Rooting, installing untrusted apps
• Physical access: Device theft, loss

What's Next?

Now that you understand the importance and impact of improper credential usage:

1. Attack Vectors: Learn how attackers discover and exploit credential issues
2. Prevention: Implement secure credential management practices
3. Examples: See vulnerable vs secure code patterns
4. Lab: Practice identifying and fixing credential issues

Key Takeaways

✅ Never hardcode credentials in mobile application source code

✅ Always use platform-provided secure storage (Keychain/KeyStore)

✅ Implement proper encryption for any stored credentials

✅ Avoid logging sensitive information at all costs

✅ Use certificate pinning for API communications

✅ Implement secure token refresh mechanisms

✅ Regular security audits of credential handling

✅ Assume the device is compromised when designing security

---

Remember: In mobile security, credentials are the keys to the kingdom. Protect them accordingly. Part of OWASP Mobile Top 10 - Educational Repository