According to OWASP, Insufficient Cryptography has gone from being the fifth leading cause of security vulnerability in mobile applications in 2016 to the second leading cause in 2021. Strong encryption can be the last line of defence to prevent data from falling into the wrong hands.
It goes without saying that devs thrive on built-in encryption code and encryption algorithms to protect their data at rest and in transit. However, encryption relies on the secrecy of the keys used to encrypt and decrypt the data. As we’ve seen with past breaches, poor key management processes and application developers often fail to protect the keys properly. The following 3 vouch for such failures:
- Hard-coded Password,
- Broken Crypto Algorithm
- Low amount of Entropy
This article will explore how insufficient cryptography can leave sensitive data vulnerable and discuss steps you can take as a mobile developer to mitigate said risks.
What Is Insufficient Cryptography?
Succinctly put, insufficient cryptography in the context of mobile applications is encryption that can easily be undermined. This could be due to flaws in the encryption process or due to the usage of weak encryption algorithms to protect sensitive data.
As mobile developers, you need to understand that the goal of cryptography is not to create ciphers that are impossible to crack but instead to make cracking them impossible in a reasonable amount of time with the current standards of computational power available.
As computational power always improves, you need to be up to date on which encryption algorithms can hold their own for at least a few years into the future.
Vulnerability Scale: Accessing Vulnerability
As mentioned earlier, two primary factors result in mobile app insufficient cryptography. These include:
- Flaws in the implementation of cryptography leave it vulnerable to exploitation.
- Usage of weak cryptographic algorithms.
Here are some scenarios that can help you assess if your mobile application suffers from insufficient cryptography:
- Reliance on only built-in code encryption processes: Mobile operating systems do have code encryption built into their operating systems. These, however, are not very secure and can be accessed via jailbroken/rooted devices.
Threat agents can go one step further and use freely available tools such as ClutchMod or GBD, take snapshots of the decrypted application code captured from memory, and then use tools such as IDA pro or Hopper to perform a static or dynamic analysis and conduct targeted binary attacks.
- Sub-standard key management processes: This is the Achilles Heel of cryptography if not implemented properly. Easily accessible encryption keys can render the strongest of encryptions useless.
Hardcoding encryption keys, storing encryption keys in the same directory with other attacker-readable encrypted data and storing strong encryption keys as plain text or even transmitting encrypting keys over an unencrypted connection such as FTP, HTTP, email, or TLS are some examples of poor key management.
- Using homegrown encryption methods: Unless you are a wizard with encryption, it’s best to stick to encryption protocols developed by security experts that are vetted by the community.
- Usage of outdated encryption protocols: Cryptographic algorithms weaken as computational power to crack them improves. Using weak protocols that are insufficient for modern security needs should be avoided at all costs.
Cryptographic functions such as RC2, MD4, MD5, SHA1, and PKCS are way past their prime and should be avoided at all costs.
Risks and Impact of Insufficient Cryptography
Insufficient cryptography can have significant technical and business impacts. Application security exists for one reason only – to protect sensitive data. Sensitive data can include users’ private information such as their bank account info, credit card numbers, addresses, government id numbers, and so on. They can also include information crucial to the application’s security, such as encryption keys, usernames, and passwords.
From a technical perspective, weak cryptography can make accessing any of the above-mentioned sensitive data a walk in the park for threat agents.
From a business perspective, the access of sensitive data by treat agents results in Privacy Violations, Information theft, Code theft, Intellectual Property Theft and irreversible reputational damage.
To help you understand what’s at stake, here is a real-world example: Insufficient Cryptography in the Philips HealthSuite Health Android app left it open to hacking where threat agents could have gotten access to private medical information about their heart rate activity, sleeping habits, blood pressure, and body composition analysis.
Though no real harm was done in this case, it is pretty evident that attention should be paid during the application development and testing phases to implementing strong cryptographic security.
How to Prevent Insecure Cryptography in Mobile Applications?
Apart from stating the obvious, stronger cryptography is the best way to secure mobile applications. That being said, here are a few key points to keep in mind while developing mobile applications that can help you prevent mobile app insufficient cryptography.
- Use encryption standards that you know will hold their own for at least 10 years into the future.
- Avoid storing sensitive data unencrypted.
- Avoid using easily-guessable encryption keys.
- Follow NIST guidelines on recommended algorithms.
This is a partial examination of all the ways that can lead to insufficient cryptography. Still, it should provide some insight into the common scenarios that you, as mobile application developers, can avoid in improving the overall security of mobile applications. Cryptography is a complex subject; it’s best to use well-known and trusted libraries created by experts. This will give you, as programmers, the best chance of avoiding cryptographic failures.
How AppSealing Makes a change?
AppSealing protects your sensitive data by building end-to-end data encryption for mobile apps. Deployment is easy to secure common security processes, such as authentication tokens, unique identifiers, passwords, and other resources, from unauthorised access, theft, deletion, or alteration – and all this without interfering with predefined workflows