Sam Craig
April 8, 2022
Application-Layer Encryption Compliance Data Security Encryption

Practical Guidance on How to Prevent Cryptographic Failures (OWASP Top Ten A02:2021)

Writer’s comment: This blog is the second in a multi-part series where we’ll provide practical recommendations for the 15 prevention measures suggested by OWASP to address the A02:2021 – Cryptographic Failures vulnerability.

As it does every few years, the Open Web Application Security Project (OWASP) published an update to its list of Top Ten Web Application Security Risks (often called the “OWASP Top 10”) in 2021. Among the changes in this update, the new Top 10 includes “Cryptographic Failures” as the number two risk facing web applications today (behind only “Broken Access Control” in the number one spot).

This change is described by OWASP as follows:

A02:2021-Cryptographic Failures shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.

Many teams across the tech community have the misperception that the Cryptographic Failures vulnerability represents a complete lack of encryption. While the lack of encryption is a serious concern, the focus of Cryptographic Failures – and the more difficult problems to identify and solve – are the poor implementation of cryptography and bad key management.

OWASP’s recent change also supports the commonly held view across the security community that at-rest encryption is not a solved problem and most existing at-rest encryption solutions, such as transparent disk encryption and full disk encryption (e.g., database encryption, cloud storage encryption), are ineffective against modern attacks.

Due to the complexity of implementing strong cryptography, the OWASP Page for Cryptographic Failures provides a section titled “How to Prevent, which begins with the statement: “Do the following, at a minimum, and consult the references.” The section then provides a bulleted list of fifteen recommendations, which are transcribed in (the left column of) the table below.

In this blog post (and in the table below, we provide our recommendations for how engineering, DevOps, and application security teams can implement most of the 15 guidance items, by leveraging Ubiq’s API-based encryption and key management as code platform.

OWASP Prevention Guidance (source)

Our Recommendation

Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.

Data classification is an important first step in an overall data protection scheme. The minimum standard for data encryption is driven by legal and regulatory compliance requirements, but there are often business or security needs that necessitate going beyond the minimum. The different classifications will define which data needs to be encrypted (and which does not), as well as group data into appropriate cohorts for defining what key management and access controls. Importantly, data in the same classification will warrant similar encryption protections, but that does not mean that they should share keys.

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.

As part of the data classification effort mentioned above, organizations will often identify some data that they are storing, but do not use. Often this is due to an incomplete picture of the business needs and an attitude of “we may want this later”. Instead, organizations should approach this issue by defining the data that needs to be stored and not holding onto anything else. Any data that can be discarded rather than stored is data that does not need to be protected and will save the organization in both storage and maintenance costs. For tokenization of sensitive information such as payment card data, Ubiq offers Format Preserving Encryption (FPE). This allows for storage of encrypted data in locations that are expecting plaintext data in a specific format rather than binary encrypted data.

Make sure to encrypt all sensitive data at rest.

The data classification will identify which data is “sensitive” and qualifies for encryption at rest. Ubiq makes data at rest encryption simple for developers to implement and for security / operations teams to manage.

Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.

Choosing strong encryption algorithms, modes, and key lengths is a crucial component of a successful cryptographic system. In most cases, AES with a 256-bit key, RSA with a 2048+ bit key, or SHA256+ are good, secure choices. Several block cipher modes are available with different performance and resilience characteristics. The one mode to be avoided due to weak security is the simplest: Electronic Code Book (ECB). With Ubiq, developers do not choose or specify cryptographic algorithms or modes. Instead, they are specified in the Ubiq web portal and weak, deprecated items (e.g., CBC mode) are not available. Ubiq also provides easy, web-based management of cryptographic keys, including creation, rotation, and expiration and secure storage in FIPS 140-2 compliant Hardware Security Modules (HSM).

Encrypt all data in transit with secure protocols such as TLS with forward secrecy (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).

Cryptography is used for two major purposes: to protect data when stored (at rest) and to protect data when sent over a network (in transit). Protection of data in transit is largely handled by Transport Layer Security (TLS) or the older Secure Sockets Layer (SSL) protocol. TLS is a strong protocol, but there are opportunities for misconfiguration or implementation flaws that can lead to compromise of the protected data. In addition, TLS is often implemented at a lower level of the “stack” where an application may not have much visibility or control. Therefore, applications may use an encryption mechanism such as Ubiq to provide an additional layer of security and to achieve more stringent use cases such as link encryptionend-to-end encryption, or point-to-point encryption for sensitive financial transaction data or secure IoT communications.

Disable caching for response that contain sensitive data.

This advice targets the storage of web pages and components by web browsers to improve performance. These stored (cached) resources are not encrypted and therefore can expose sensitive data. When caching is implemented by a client application, that application can choose to store data in an encrypted state. Ubiq’s easy-to-use, high-performance cryptography can streamline implementation of this approach.

Apply required security controls as per the data classification.

Data encryption, such as provided by Ubiq, is an important method to implement security controls. It is typically not the only mechanism required to protect sensitive data, however. Ensure that other appropriate controls are also implemented to provide all protections prescribed by the data classification policy.

Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.

Legacy, unencrypted protocols should be avoided due to their inherent insecurity. In some cases, however, interoperability or business needs will require their use. When insecure protocols are used, it is critical that applications and systems implement additional layers of cryptographic protections.

Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.

When implementing password authentication, the original, plaintext password should never be stored. Instead, use a strong, purpose-built password hashing algorithm and store only the resulting, hashed data. Ubiq does not handle passwords or provide password hashing functionality.

Initialization vectors must be chosen appropriate for the mode of operation. For many modes, this means using a CSPRNG (cryptographically secure pseudo random number generator). For modes that require a nonce, then the initialization vector (IV) does not need a CSPRNG. In all cases, the IV should never be used twice for a fixed key.

A non-random Initialization Vector (IV) exposes a cryptographic system to several attacks. When needed, Ubiq generates an IV for encryption within the Ubiq client library. The IV is created using a cryptographically secure random method appropriate for the client application language and platform. Ubiq never reuses an IV – whenever an IV is needed, Ubiq securely generates a fresh one.

Always use authenticated encryption instead of just encryption.

Being able to verify the source of encrypted data is important in protecting against some replay and spoofing attacks. Ubiq provides only authenticated encryption, specifically using Galois/Counter Mode (GCM).

Keys should be generated cryptographically randomly and stored in memory as byte arrays. If a password is used, then it must be converted to a key via an appropriate password base key derivation function.

Truly random keys are critical to the security of cryptographic systems. Ubiq generates keys using cryptographically secure mechanisms on the Ubiq cloud platform. The Ubiq client libraries define and handle keys using language-appropriate binary data types. Ubiq does not use passwords to derive keys.

Ensure that cryptographic randomness is used where appropriate, and that it has not been seeded in a predictable way or with low entropy. Most modern APIs do not require the developer to seed the CSPRNG to get security.

As covered in rows above, truly random numbers are often required by cryptographic systems. Ubiq uses secure, cryptographic randomness where appropriate, such as in initialization vector and key generation. Ubiq automatically and securely initializes its randomness sources without the need for seeding or other developer actions.

Avoid deprecated cryptographic functions and padding schemes, such as MD5, SHA1, PKCS # 1 v1.5.

A complicating factor in many cryptographic libraries and systems is the number of algorithms and schemes that are available. Particularly, systems often support old, insecure items that should not be avoided unless needed for interacting with older systems and data. With Ubiq, developers do not choose or specify algorithms or modes. Instead, they are specified in the Ubiq web portal and deprecated items are not available.

Verify independently the effectiveness of configuration and settings.

Errors in the use or implementation of cryptography can be difficult to detect, but even a small mistake can completely compromise the security of encrypted data. A major factor in avoiding cryptographic implementation issues is to simplify the process. With Ubiq, developers are not responsible for cryptographic settings since they are configured in the web portal rather than in code. The Ubiq portal also provides access to activity logs for the use of keys to encrypt and decrypt data as well as all encrypt and decrypt operations. Therefore, settings and logs are easily accessible to the security and audit and compliance teams as needed.

Up Next

The OWASP page for A02 Cryptographic Failures – OWASP Top 10:2021 also contains a section titled “List of Mapped CWEs,” which provides a list of 29 Common Weakness Enumeration (CWE) entries that are associated with Cryptographic Failures. We will cover most of those weaknesses in detail in future posts, where we’ll describe the vulnerability, why it happens, a real-world case study, and recommended mitigations. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog below.

Get radically effective data-level security. Get Ubiq.