> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# A02:2021  - Cryptographic Failures

> Security rules for Cryptographic Failures vulnerabilities. Failures related to cryptography which often lead to sensitive data exposure. This includes the use of weak or broken cryptographic algorithms, improp

Failures related to cryptography which often lead to sensitive data exposure. This includes the use of weak or broken cryptographic algorithms, improper key management, weak random number generation, and transmission of data in cleartext.

<Info>
  CodeAnt AI detects **Cryptographic Failures** vulnerabilities across **18 languages**: Python, Java, JavaScript, TypeScript, Go, C#, Ruby, PHP, Kotlin, Swift, Rust, Scala, C++, Clojure, Elixir, Terraform, HTML, YAML.
</Info>

***

## Detected Vulnerabilities

<AccordionGroup>
  <Accordion title="CWE-327: Use of Broken or Risky Cryptographic Algorithm">
    **Severity:** **High**

    ### Description

    The application uses a broken or risky cryptographic algorithm such as MD5, SHA1, DES, or RC4, which have known vulnerabilities that can be exploited by attackers.

    ### Impact

    Attackers can forge signatures, recover plaintext from encrypted data, or create hash collisions, undermining the security guarantees the cryptography was intended to provide.

    ### Remediation

    Replace MD5/SHA1 with SHA-256 or SHA-3 for hashing. Replace DES/RC4 with AES-256-GCM for encryption. Use well-established cryptographic libraries. Follow current NIST recommendations.
  </Accordion>

  <Accordion title="CWE-326: Inadequate Encryption Strength">
    **Severity:** **High**

    ### Description

    The application uses a cryptographic algorithm with insufficient key length, making it feasible for attackers to break the encryption through brute-force or other attacks.

    ### Impact

    Encrypted data can be decrypted by attackers using modern computing resources, exposing sensitive information such as credentials, personal data, or financial records.

    ### Remediation

    Use minimum key lengths of 2048-bit for RSA, 256-bit for AES, and 256-bit for elliptic curve cryptography. Regularly review and update key lengths as computing power increases.
  </Accordion>

  <Accordion title="CWE-295: Improper Certificate Validation">
    **Severity:** **Critical**

    ### Description

    The application does not properly validate SSL/TLS certificates, allowing attackers to intercept encrypted communications through man-in-the-middle attacks.

    ### Impact

    All data transmitted over supposedly secure connections can be intercepted and read by attackers, including authentication credentials, session tokens, and sensitive data.

    ### Remediation

    Always validate SSL/TLS certificates. Do not disable certificate verification in production. Use proper certificate pinning where appropriate. Keep certificate stores up to date.
  </Accordion>

  <Accordion title="CWE-330: Use of Insufficiently Random Values">
    **Severity:** **High**

    ### Description

    The application uses predictable random values for security-sensitive operations such as token generation, session IDs, or cryptographic keys.

    ### Impact

    Attackers can predict generated values, allowing them to forge session tokens, bypass CSRF protections, or guess cryptographic keys.

    ### Remediation

    Use cryptographically secure random number generators (CSPRNG) for all security-sensitive operations. In Python use `secrets`, in Java use `SecureRandom`, in Go use `crypto/rand`.
  </Accordion>

  <Accordion title="CWE-319: Cleartext Transmission of Sensitive Information">
    **Severity:** **High**

    ### Description

    The application transmits sensitive data over an unencrypted channel (HTTP instead of HTTPS, unencrypted database connections, etc.), making it readable to anyone monitoring the network.

    ### Impact

    Sensitive data including credentials, personal information, and financial data can be intercepted by attackers through network sniffing, especially on shared or public networks.

    ### Remediation

    Use TLS/HTTPS for all data transmission. Enforce HSTS headers. Configure secure database connections. Use encrypted protocols for all inter-service communication.
  </Accordion>

  <Accordion title="CWE-321: Use of Hard-coded Cryptographic Key">
    **Severity:** **Critical**

    ### Description

    The application contains hard-coded cryptographic keys in the source code, making them discoverable by anyone with access to the codebase.

    ### Impact

    Hard-coded keys can be extracted from source code or compiled binaries, allowing attackers to decrypt data, forge tokens, or impersonate the application.

    ### Remediation

    Store cryptographic keys in secure key management systems (AWS KMS, HashiCorp Vault, etc.). Use environment variables or secret managers. Never commit keys to version control.
  </Accordion>

  <Accordion title="CWE-328: Use of Weak Hash">
    **Severity:** **Medium**

    ### Description

    The application uses a weak hashing algorithm for password storage or data integrity verification that does not provide sufficient collision resistance.

    ### Impact

    Attackers can find collisions or use precomputed rainbow tables to reverse hashed values, compromising password security and data integrity.

    ### Remediation

    Use bcrypt, scrypt, or Argon2 for password hashing. Use SHA-256 or SHA-3 for data integrity. Apply proper salting for all password hashes.
  </Accordion>

  <Accordion title="CWE-338: Use of Cryptographically Weak PRNG">
    **Severity:** **High**

    ### Description

    The application uses a pseudo-random number generator (PRNG) that is not suitable for cryptographic purposes in a security context, such as `Math.random()` or `random.random()`.

    ### Impact

    Security tokens, session identifiers, or encryption keys generated with weak PRNGs can be predicted, enabling session hijacking, token forgery, or cryptographic attacks.

    ### Remediation

    Replace weak PRNGs with cryptographically secure alternatives: `secrets` module in Python, `crypto.randomBytes` in Node.js, `SecureRandom` in Java, `crypto/rand` in Go.
  </Accordion>

  <Accordion title="CWE-522: Insufficiently Protected Credentials">
    **Severity:** **Critical**

    ### Description

    The application stores, transmits, or handles user credentials in an insecure manner, such as storing passwords in plaintext, using reversible encryption, or logging credentials.

    ### Impact

    Compromised credential storage leads to mass account takeover. Leaked credentials can be used for credential-stuffing attacks across multiple services.

    ### Remediation

    Hash passwords with bcrypt/Argon2 using per-user salts. Never store plaintext passwords. Use secure credential transmission. Implement credential rotation policies.
  </Accordion>
</AccordionGroup>