OWASP M10: Understanding Insufficient Cryptography Risks

When you open a banking app or share a private message, you trust that your data is safely encrypted. But that trust can shatter when cryptography itself becomes weak or poorly implemented. OWASP M10: Insufficient Cryptography highlights this risk in mobile applications, where flaws in encryption design or implementation can expose sensitive data.

Also, attackers don’t always need brute force; sometimes a single flaw in how data is encrypted is enough. From insiders who leak encryption keys to cybercriminals who exploit weak algorithms and even state-backed actors running complex decryption programs, the threat is real and varied.

Insecure cryptography doesn’t just expose data; it breaks the promise of security that every mobile app is built on.

In this blog, we’ll explain the insufficient cryptography risks in mobile applications, their causes, and best practices for prevention.

What is Insufficient Cryptography?

OWASP M10: Insufficient Cryptography risk refers to a risk that arises when encryption is weak or misused in mobile apps. This is part of OWASP Mobile Top 10 risks and understanding them can help developers toward safer coding practices. 

Poor cryptographic design can turn a secure-looking app into an easy target. Many developers still rely on outdated algorithms, hardcoded keys, or self-made encryption methods.

These shortcuts often fail under real-world pressure. Imagine a mobile wallet that stores passwords with MD5 (Message Digest Algorithm 5) or sends data without proper encryption. An attacker could easily decode that information and steal user credentials.

The goal isn’t just to use encryption but to use it correctly. Strong algorithms like AES (Advanced Encryption Standard) and RSA (Rivest–Shamir–Adleman), proper key handling, and trusted libraries are vital. They protect sensitive data, maintain user trust, and keep mobile applications truly secure.

Difference Between Insufficient Cryptography and No Encryption

Insufficient cryptography and no encryption may seem similar, but they fail in different ways. When no encryption is used, data travels or sits in plain text. Anyone who intercepts it can read it instantly.

Insufficient cryptography is trickier. It makes data look secure when it isn’t. Weak algorithms, poor key management, or flawed implementations leave cracks for attackers to exploit. Consider an app that hashes passwords with MD5 (Message Digest Algorithm 5); it looks encrypted but can be broken in seconds.

This false sense of safety is what makes it dangerous. Real protection comes from using strong, tested methods like AES (Advanced Encryption Standard) and proper key handling that keep data private and tamper-proof.

Causes of Insufficient Cryptography Risk

Weak cryptography rarely happens by accident. It often stems from small coding shortcuts, overlooked configurations, or misplaced trust in libraries and frameworks that appear secure but quietly introduce serious vulnerabilities. Here are some primary reasons for weak cryptography risks in mobile apps:

• Developer misconceptions: Many assume that using AES ensures strong encryption, but that’s only part of the equation. Without secure key generation, mode selection (like GCM over CBC), and randomness, even AES can offer little real protection.
• Platform API misuse (iOS & Android): Native cryptographic APIs are easy to misuse. Developers often rely on insecure defaults, skip essential parameters, or handle keys improperly, leading to fragile implementations. 
• Android Keystore misuse: The Android Keystore is meant to protect cryptographic keys in hardware-backed storage, but developers often misconfigure it. Storing keys outside, failing to enforce authentication, or exporting keys for convenience undermines the entire purpose of secure key management.
• iOS Common Cryptography missteps: Ignoring low-level cryptographic details can prove risky. Developers often misuse padding, hardcode IVs, or select outdated modes, weakening encryption silently. These issues don’t raise functional errors but can expose data to decryption or tampering in real-world scenarios.
• Cross-platform frameworks: Frameworks like React Native or Flutter abstract away native security features, limiting control over how encryption is applied. This abstraction can hide insecure defaults and prevent hardware-backed key usage. 
• SDKs that silently weaken crypto hygiene: Third-party SDKs can introduce cryptographic flaws without developers realizing it. Issues like hardcoded keys, weak encryption, or improper certificate validation may be buried in precompiled or obfuscated code. 

How Attackers Exploit Weak Cryptography

Cryptography is only as strong as its implementation. Poor coding practices, outdated protocols, or lack of oversight can result in serious vulnerabilities. Below are common ways attackers exploit weak cryptography:

• Reverse Engineering App Binaries: Unprotected binaries make it easy for attackers to extract hardcoded credentials, encryption keys, or sensitive logic. Once exposed, these secrets become direct entry points for exploitation.
• Brute-Forcing or Decrypting with Known Flaws: Outdated algorithms like MD5, RC4, or SHA-1 help attackers carry out brute-force attacks using GPU clusters, breaking encrypted data through mathematical weaknesses.
• MITM Attacks Due to Improper TLS/SSL Implementation: Misconfigured TLS, missing certificate validation, or weak cipher suites allow attackers to intercept traffic and perform man-in-the-middle (MITM) attacks.
• Memory Scraping and Debugging in Rooted Environments: Rooted or jailbroken devices bypass OS-level protections, allowing attackers to extract session tokens, decrypted data, or tamper with encryption libraries.

Business Impact of Insufficient Cryptography Risks

Insufficient cryptography weakens the foundation of mobile security. When encryption is implemented incorrectly, sensitive data is exposed. Weak algorithms, short key lengths, or flawed practices compromise confidentiality and integrity.

Common issues like insecure key management, predictable random number generation, and improper handling of encryption processes create silent entry points for attackers. Vulnerable cryptographic libraries and protocols can be exploited to intercept communication or manipulate data.

Outdated hash functions like MD5 or SHA-1 remain risky. Attackers can reverse-engineer hashed data or generate collisions to reveal original information. Such flaws have led to large-scale breaches in mobile and backend systems alike.

The solution lies in strong algorithms like AES and SHA-256, secure key storage, code reviews, penetration testing, and regular audits. Continuous updates and adherence to security standards help maintain user trust.

Real-World Examples of Insufficient Cryptography in Mobile Applications

The following two incidents show how poor encryption in mobile apps can lead to serious data exposure and loss of trust.

Example #1: Location Data Breach

In January 2025, a security breach involving Candy Crush and Tinder revealed how fragile mobile data protection can be. A location data broker suffered a breach that exposed terabytes of user location data stored on Amazon cloud servers.

The issue wasn’t the cloud but how the data was handled. Real-time location details were stored without strong encryption or consistent cryptographic controls. Attackers exploited weak encryption to access sensitive location data, including movements near government and military sites.

The fallout was severe. Users faced privacy risks as their real-world movements were exposed and misused. The incident also eroded public trust and emphasized the importance of AES-256-level encryption.

Example #2: Infostealer Log Exposes User Data

In October 2025, the “Synthient Stealer Log Threat Data” breach exposed around millions of email addresses and passwords collected from compromised devices. The breach wasn’t linked to Google or Apple but to mobile apps on compromised devices that failed to encrypt credentials properly.

Attackers used the exposed data for account takeovers, financial fraud, and identity theft. The case highlighted the urgent need for robust encryption and periodic cryptographic audits in mobile app development.

Together, these examples show how insufficient cryptography can have lasting consequences. 

Best Practices for Prevention

Secure-by-default SDKs and Frameworks

• Ship SDKs and frameworks with secure default configurations.
• Disable unnecessary features by default.
• Provide safe defaults for permissions and access controls.
• Regularly update SDKs to patch vulnerabilities.

Secure Code Review Practices for Crypto Usage

• Verify correct algorithm selection.
• Use secure random number generators.
• Confirm correct encryption modes and padding.
• Ensure no hardcoded keys or secrets exist in code.

Threat Modeling for Data at Rest and in Transit

• Identify assets, data flows, and trust boundaries.
• Analyze threats for storage and transmission.
• Include insider threats and data leakage scenarios.
• Update models as architecture evolves.

Compliance Frameworks (PCI-DSS, HIPAA, GDPR)

• PCI-DSS mandates encryption of cardholder data.
• HIPAA requires encryption of protected health information.
• GDPR enforces encryption for personal data privacy.
• Access to encrypted data must follow least-privilege principles.

Standard Guidelines

• Use platform-native cryptographic APIs like CryptoKit and Android Keystore.
• Protect keys using hardware-backed modules (Secure Enclave, StrongBox).
• Always encrypt sensitive local data.
• Implement TLS for all communications.

Algorithms and Protocols

• Prefer AES-GCM, SHA-256, and RSA-2048 or higher.
• Avoid deprecated algorithms like RC4, MD5, or SHA-1.

Key Management and Randomness

• Store keys securely and rotate regularly.
• Use OS-level secure keystores.
• Enforce least privilege for key access.
• Use cryptographically secure random number generators.

TLS with Certificate Pinning

• Use TLS 1.2 or higher with strong cipher suites.
• Implement certificate pinning to prevent MITM attacks.
• Regularly update and monitor certificates.

Developer Education

• Train developers on secure crypto concepts.
• Highlight risks of weak algorithms and insecure randomness.
• Promote the use of vetted libraries instead of custom crypto code.

Conclusion

Insufficient cryptography is one of the most overlooked yet damaging vulnerabilities in mobile app security. It hides behind the illusion of protection, but a single weak cipher or mismanaged key can open the door to massive data leaks, privacy violations, and compliance failures. 

Developers and businesses must move beyond surface-level encryption and embrace strong, tested algorithms with disciplined key management. In a mobile-first world where every byte of data carries value, securing encryption is not just good practice, it’s a responsibility.

Protect your mobile applications from cryptographic failures. Strengthen your encryption, secure your keys, and perform regular audits to maintain trust and compliance. Contact us today to  secure-by-design mobile systems today.

FAQs