> ## 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.

> [!NOTE]
>
> 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.

***

## Detected Vulnerabilities

> [accordion] 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] 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] 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] 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] 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] 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] 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] 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] 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.