OWASP Top 10 – A02 Cryptographic Failures - Part 1

This is part 1 of my posts on Cryptographic Failures. It is part of a series of blog posts about the OWASP Top 10 . Cryptographic failures remain one of the leading causes of data breaches, and understanding them is key for developers.

This post introduces number 2 on the OWASP Top 10 list (2021): Cryptographic Failures . I’m writing this post as part of my own learning, and I hope it helps others along the way. I would highly recommend reading the entire OWASP page to gain an understanding of the nature of the vulnerability.

You can find the OWASP Top 10 List here .

According to OWASP’s description of A02:2021 – Cryptographic Failures:

“The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#description )

OWASP goes on to provide practical examples of what this means in real-world scenarios, such as asking “Is any data transmitted in clear text?”, “Are any old or weak cryptographic algorithms or protocols used by either default or in older code?”, etc.

In the overview section on the same A02 page, OWASP also states that the category “…is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof). Which often lead to exposure of sensitive data.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#overview )

In the first few posts in this series, I’ll take a high-level look at OWASP’s prevention guidance, and in later posts, I’ll dive deeper into specific areas. There is a lot of information to cover, so the introduction will be broken into multiple posts; this one will cover the first four prevention steps recommended by OWASP.

OWASP states:

“Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.”(https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )

In many cases, your system will be subject to regulations such as GDPR, HIPAA, PCI DSS, etc. Even in rare cases where your system is not subject to any regulatory requirements, you will still need to identify which data is sensitive according to your business needs.

Software developers have an ethical responsibility to protect user data. Ask yourself, would any data stored in your application cause harm to a user if it were to be exposed? A compromised library card number, for example, may not lead to significant harm to a user. A compromised social security number, however, would be extremely harmful to the individual. It is up to you and/or your team to identify the data you are storing and make sure to take precautions to protect user data.

OWASP states:

“Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS–compliant tokenization or even truncation. Data that is not retained cannot be stolen.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )

Don’t store sensitive data if you don’t need to. In some cases, storing sensitive data is unavoidable. For example, a patient’s medical record number is a key piece of information in an electronic medical record and must be stored in some tables to correctly identify the patient.

In other cases, however, it is unnecessary to store sensitive data. Credit card numbers are a good example. If your data somehow gets obtained by an attacker, e.g., a copy of your database is somehow stolen, it’s a much better scenario if the sensitive data was never stored. This is why some web sites require you to re-enter your credit card number every time you make a purchase. They simply aren’t storing it.

OWASP also highlights approaches such as tokenization and/or truncation, both of which are defined in PCI DSS. While an in-depth exploration of these concepts is outside the scope of this blog post, here is a simplified overview:

Tokenization: A token is created that represents the sensitive data. This token is then stored instead of the sensitive data. When the actual sensitive data is needed, the token is used with the PCI DSS–compliant system to complete the transaction. These PCI DSS–compliant vaults are usually maintained by a third-party, whose system implements the required PCI DSS–compliant security.

Truncation: Storing part of a sensitive data element, rather than all of it. For example, a system that stores your credit card may store only the last 4 digits of a credit card number. This is truncation. PCI DSS allows storing the first 6 + last 4, but never the full Primary Account Number (PAN).

Tokenization and truncation are often used together. Tokenization would be used to store the surrogate token from the PCI DSS–compliant system, and the “truncated” version, i.e., only the last 4 digits, would be stored in the database for display purposes.

A payment site that presents a card number may take the truncated data and then apply masking to display the card number in the format **** **** **** 1234.

NOTE: Masking is a display control only. It does not reduce risk if the full sensitive data element is stored behind the scenes.

In such cases, a PCI DSS–compliant system would then be used to complete the transaction; you may still be asked to enter the 3-digit card security code. This is another example of not storing sensitive data unnecessarily. It adds an extra layer of security by not storing the security code. It also requires you to provide the code from the physical card which is, presumably, in your possession.

Credit cards are a common example, but the principle applies to many types of sensitive data.

OWASP states:

“Make sure to encrypt all sensitive data at rest.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )

It is best practice to encrypt all sensitive data at rest. Here are a few common methods to encrypt at rest.

• Transparent Data Encryption (TDE)

  Transparent Data Encryption (TDE) is a technology used by database engines to encrypt database files. Using TDE, the data is automatically encrypted when written to the database and automatically decrypted when read.

• File System Encryption

  File System Encryption is an encryption method where the entire file system is encrypted. AWS for example, now automatically encrypts data at rest with AWS FSx and AWS EFS. AWS S3 object storage, which is often used like a file system, also automatically encrypts data at rest.

  In 2017, Equifax disclosed a breach exposing sensitive consumer data that was not encrypted at rest.

• Application Level Encryption

  Application Level Encryption involves using the encryption capabilities of your application’s language and/or available frameworks. This includes APIs like the .NET data protection api (DPAPI) or the Sodium extension in PHP.

• Database Level Encryption

  Database Encryption is using the encryption capabilities of the database to encrypt data at the column level. MySQL, for example, supports AES_ENCRYPT and AES_DECRYPT functions for encrypting individual columns.

AES_ENCRYPT/AES_DECRYPT use defaults that may not align with best practices (e.g., key length, modes). Review your encryption configuration carefully and do not assume the defaults are safe.

Which option is the right fit for a system depends on the specific needs of the application.

While encrypting data at rest is a significant step towards a more secure application, there are risks it does not address. For example, Transparent Data Encryption (TDE) typically automatically decrypts data read by authenticated users. So, TDE protects against things like stolen physical media, but does not mitigate risks such as an attacker obtaining valid credentials to your system, or unauthorized access from within your own company. For some data, application-layer encryption may also be required in addition to TDE for additional protection. That being said, encrypting all sensitive data at rest is essential for secure systems, and is a requirement of regulations like the GDPR, HIPAA and PCI DSS.

OWASP states:

“Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )

Let’s look at this one part at a time:

• Ensure Up-to-date and Strong Standard Algorithms Are in Place.

  Many algorithms that were once considered secure are no longer recommended for use. Before choosing encryption algorithms, make sure to check that any algorithms you plan to use are up-to-date, not deprecated, and comply with current security standards.

  OWASP has created some great resources to help with this, including their Cryptographic Storage Cheat Sheet and Password Storage Cheat Sheet .

  Always use strong algorithms for encryption and never write your own.

• Ensure Up-to-date and Strong Protocols Are in Place.

  In this context, OWASP is referring to cryptographic and communication protocols. These include items like using the most current version of TLS/HTTPS for web traffic, using SSH/SFTP for file transfer, etc.

• Ensure Up-to-date Keys Are in Place; Use Proper Key Management.

  Here, the OWASP guidance is referring to a few different things.

  1. Key size & strength.

     • For example, for RSA-based encryption, a key should use at least 2048 bits, but as of the date of this post, 3072+ is the recommendation for long-term security.

  2. Key Rotation and Management

     • Keys should not live forever and should be rotated regularly. In the simplest terms, key rotation is like changing a password. The old key should be “rotated” out of use and a new key should be “rotated” into use. One implementation of this is decrypting the data using the old key and re-encrypting it with the new key. Ideally, a Key Management System such as AWS KMS (Key Management Service) or Azure Key Vault would be used to handle encryption.

  3. Algorithm-Key Compatibility

     • Don’t use short keys with strong algorithms.

     • Use cryptographically secure random number generators when randomness is needed for encryption.

  Use proper key management and never hard-code keys in source code.

In this post, we introduced the concept of cryptographic failures – Item #2 on the OWASP Top 10 list as of 2021. We looked at the first four items on the OWASP prevention list for this category of vulnerability. In the next post, we’ll continue working through OWASP’s prevention guidance for cryptographic failures, looking at additional best practices to help prevent cryptographic failures.