Learnitweb

A02:2021 – Cryptographic Failures

—

by

Editorial Team
in

1. Overview

A02:2021 – Cryptographic Failures is one of the security risks identified in the OWASP Top 10 for 2021. It highlights vulnerabilities caused by improper implementation, use, or management of cryptographic systems in applications.

Cryptographic failures occur when sensitive data is inadequately protected. This category was previously called “Sensitive Data Exposure” but was renamed to emphasize the root cause: improper cryptographic practices.

2. Description

To ensure data security, it is essential to assess the protection requirements for data both in transit and at rest. Sensitive information such as passwords, credit card details, health records, personal identifiers, and corporate secrets demand robust security measures, especially when subject to privacy laws (e.g., EU’s GDPR) or industry regulations (e.g., PCI DSS for financial data). Key considerations include:

  1. Data Transmission
    • Clear Text Transmission: Are any sensitive data transmitted in plain text over insecure protocols such as HTTP, SMTP, or FTP? Even when using TLS upgrades like STARTTLS, external internet traffic poses significant risks.
      • Verify the security of all internal communication, including traffic between load balancers, web servers, and backend systems.
  2. Cryptographic Algorithms and Protocols
    • Legacy or Weak Protocols: Are outdated or weak cryptographic algorithms (e.g., MD5, SHA-1) or insecure protocols used in any part of the system?
    • Mode of Operation: Are insecure cipher modes like ECB (Electronic Codebook) in use? Are initialization vectors (IVs) improperly managed (e.g., reused, ignored, or weakly generated)?
  3. Key Management
    • Default or Weak Keys: Are default cryptographic keys being used? Are keys weakly generated, reused, or poorly managed without proper rotation policies?
    • Source Code Exposure: Are encryption keys inadvertently checked into source code repositories?
  4. Encryption Enforcement
    • Missing Security Headers: Is encryption enforcement neglected? For instance, are essential HTTP security headers or browser directives missing?
    • Server Certificates: Are server certificates and their trust chains validated correctly?
  5. Password and Key Derivation
    • Key Derivation Functions (KDFs): Are passwords directly used as cryptographic keys instead of being processed through secure password-based key derivation functions (e.g., PBKDF2, bcrypt, Argon2)?
  6. Randomness and Entropy
    • Inadequate Randomness: Is the randomness used for cryptographic purposes subpar or insufficiently unpredictable? If developers need to seed random number generators, is the seeding process robust and secure?
  7. Hashing and Padding
    • Hash Functions: Are deprecated cryptographic hash functions (e.g., MD5, SHA-1) still in use? Are non-cryptographic hash functions used where cryptographic ones are needed?
    • Padding Methods: Are outdated padding methods like PKCS #1 v1.5 in use?
  8. Error Handling and Side-Channel Vulnerabilities
    • Exploitable Errors: Are cryptographic error messages or side-channel information (e.g., timing or padding oracle vulnerabilities) exploitable?

3. How to Prevent

Do the following, at a minimum:

  • Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
  • 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.
  • Make sure to encrypt all sensitive data at rest.
  • Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
  • 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).
  • Disable caching for response that contain sensitive data.
  • Apply required security controls as per the data classification.
  • Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.
  • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
  • 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.
  • Always use authenticated encryption instead of just encryption.
  • 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.
  • 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.
  • Avoid deprecated cryptographic functions and padding schemes, such as MD5, SHA1, PKCS number 1 v1.5 .
  • Verify independently the effectiveness of configuration and settings.

4. Example Attack Scenarios

  • Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit card numbers in clear text.
  • Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g., the recipient of a money transfer.
  • Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.