Cryptographic Issues Are a “Top Three” Application Flaw
Image credit: Photo by @jaye_haych
Data protection is an essential part of many modern applications. In recent years the data protection regulatory landscape has grown increasingly complex. With new laws like GDPR, CCPA and PDPA joining existing regulations such as HIPAA and PCI DSS, organizations have a responsibility to properly protect the sensitive data in their possession.
As this definition of protected data expands, the use of cryptography in applications grows. Data encryption is an essential component of data protection, and developers need to incorporate it into any applications transmitting, processing, or storing sensitive data.
However, cryptographic implementations are fragile, and a small error can significantly weaken or completely destroy the protections that they provide. This is a significant concern because, according to a survey conducted by Veracode in 2020, that looked at data from over 130,000 live applications, cryptographic issues are the third most common application vulnerability and appear in 63.7% of applications.
The implications of these cryptographic vulnerabilities are significant. A simple flaw in a cryptographic implementation can expose an organization to a data breach and make it subject to fines for regulatory non-compliance under new laws. This can be upwards of 10% of a company’s annual revenue. It’s like leaving your keys in your door.
Where Cryptography Goes Wrong
Even security veterans can struggle with cryptography because there are a number of subtle ways in which cryptographic algorithms can go wrong if implemented incorrectly. These issues can be summarized into the following categories.
Poor Password Management
Password-based authentication is common for applications because it is easy to understand, easy to use, and easy to develop. However, password management is easy to get wrong. Secure password management requires storing passwords as hashes generated using a secure hash algorithm. To defend against dictionary attacks, a random salt is added to the password prior to hashing. If any of these conditions are violated, then the password is insecure.
Multiple companies have reported data breaches involving passwords stored using insecure hash functions (like SHA-1 or MD5) or misusing password salts. In some extreme cases, possibly due to ease of implementation, passwords were stored in plaintext without any protection. In March 2019, Facebook revealed that its developers inappropriately had access to plaintext user passwords for seven years. The reason is that these passwords were included in log files stored on the company’s servers.
Weak Pseudorandom Number Generation
The use of random numbers in software is not a novel concept. Many different types of applications need the ability to select “randomly” from a number of different options.
In most cases, this “random” choice does not need to be truly random. All that is needed is a certain level of unpredictability that can be provided by a number of different pseudorandom number generators (PRNGs). In a scientific experiment, for example, randomness may be required, but the potential for someone to try to break the system is not a concern.
The same cannot be said for the use of random numbers in cryptography. Cryptographic algorithms commonly use random number generators to produce the secret keys that encrypt and decrypt sensitive data. If the random number generation process is predictable, an attacker will be able to “guess” a user’s encryption key and decrypt the data.
Weak random number generation is commonly seen in the cryptocurrency space. In one instance, a “Blockchain Bandit” searched for Ethereum users that used an insecure protocol for generating the secret keys associated with their blockchain accounts. This attacker managed to steal millions of dollars’ worth of cryptocurrency by exploiting this vulnerability.
The issue is so severe that the Monetary Authority of Singapore recommends that randomness be validated for financial services use.
*MAS Technology Risk Management Guidelines 2021
Fixing these types of vulnerabilities in an application is fairly simple. Instead of using the weak pseudorandom number generators designed for scientific experiments and similar applications, use a cryptographically secure PRNG instead.
Use of Insecure Cryptography
Secure encryption algorithms (i.e., strong cryptography) are highly resilient against attack if used correctly. These are algorithms have been subjected to cryptoanalysis and source code review by many researchers for exploitable vulnerabilities. Currently, the recommended ones for use have either not been broken yet or existing attacks are too impractical. However, these protections only apply if the algorithms are used in the way that they were designed. Tip: Ensure your team follows the recommendations from NIST accordingly.
A custom cryptographic protocol is even more likely to contain exploitable vulnerabilities – due care must be taken in all aspects of implementation. Even an experience dev team can make mistakes as demonstrated by the Zerologon vulnerability in 2020. This vulnerability existed due to use of a custom block cipher mode of operation for encryption with AES. As a result, vulnerable domain controllers (DC) could be exploited to give an attacker full control over the network managed by the DC. The lesson of Zerologon is simple. Never try to roll your own cryptography.
Implementing Secure, Simple Cryptography
Cryptography is an important part of many applications and is very easy to get wrong. A simple mistake can invalidate the protection provided by encryption algorithms, and almost two-thirds of applications make these simple mistakes.
When adding cryptography to an application, it is always better to use a secure, trusted implementation. Ubiq makes secure encryption easy by providing developers with painless access to secure, correct implementations of cryptographic functionality. To find out more about how to quickly build data encryption into any application, watch our short demo video.