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

OWASP Prevention Guidance (source)

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 encryption, end-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.