Cryptographic Failures: OWASP A02 Explained with Examples and Fixes

In the 2021 OWASP Top 10 update, "Sensitive Data Exposure" was renamed and elevated to the #2 position as "Cryptographic Failures." The name change was deliberate. The old name described the symptom (data got exposed). The new name describes the root cause (cryptography was absent, weak, or improperly implemented). Every sensitive data exposure traces back to a cryptographic failure: data wasn't encrypted, was encrypted poorly, had keys mismanaged, or was transmitted without protection.

Cryptographic failures sit at #2 on the OWASP Top 10 because they directly enable data breaches. When an application stores passwords in plaintext, transmits credit card numbers without TLS, uses MD5 to hash sensitive data, or embeds encryption keys in source code, the result is exposed data. Not hypothetically. Provably. Attackers who reach the data find it readable, crackable, or decryptable because the cryptography protecting it either didn't exist or didn't work.

This guide covers what OWASP A02 Cryptographic Failures means in practice, walks through every common cryptographic failure category with real code examples showing the vulnerable pattern and the secure fix, explains how web application penetration testing discovers these failures, and provides the remediation guidance developers need to eliminate cryptographic weaknesses from their applications.

What Are Cryptographic Failures?

Cryptographic failures occur when an application fails to adequately protect sensitive data through cryptography. This includes data in transit (network communication), data at rest (databases, files, backups), and data in use (memory, logs, error messages).

Why OWASP Elevated This to #2

The OWASP Top 10 2021 moved this category from #3 ("Sensitive Data Exposure" in the 2017 list) to #2, reflecting that cryptographic failures are among the most common and highest-impact vulnerability categories. The rename from "Sensitive Data Exposure" to "Cryptographic Failures" shifted focus from the consequence to the cause, guiding developers toward the root issue.

What Counts as Sensitive Data

Before evaluating cryptographic protection, identify what requires it.

Always sensitive: Passwords, credit card numbers, health records, personally identifiable information (PII), authentication tokens, API keys, encryption keys, social security numbers, biometric data.

Sensitive in context: Internal business data, intellectual property, employee records, financial reports, legal documents, customer communications.

Regulated data requiring specific protection: Payment data (PCI DSS), health information (HIPAA), personal data of EU residents (GDPR), financial records (SOX). For compliance-specific testing requirements, see our penetration testing compliance guide.

Cryptographic Failure #1: Data Transmitted Without Encryption

The Failure

Application transmits sensitive data over HTTP instead of HTTPS. Or the application supports HTTPS but doesn't enforce it, allowing connections to downgrade to HTTP. Or internal services communicate sensitive data in plaintext because "it's internal."

Example

# VULNERABLE: API endpoint accessible over HTTP
http://api.example.com/v1/users/profile
# Returns: {"name": "John Doe", "ssn": "123-45-6789", "email": "john@example.com"}

# Anyone on the network path can intercept this in plaintext

Real-World Impact

A user on public WiFi accesses your application over HTTP. An attacker on the same network uses a packet sniffer to capture credentials, session tokens, and personal data transmitted in cleartext. No exploitation required. Just listening.

The Fix

# SECURE: Enforce HTTPS everywhere

# Nginx configuration
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_prefer_server_ciphers on;
    
    # HSTS header - tells browsers to always use HTTPS
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

Checklist:

• HTTPS enforced on all endpoints (HTTP redirects to HTTPS)
• HSTS header present with adequate max-age (minimum 1 year)
• TLS 1.2 minimum enforced (TLS 1.0 and 1.1 disabled)
• Strong cipher suites only (no RC4, DES, or NULL ciphers)
• Internal service-to-service communication encrypted
• Database connections use TLS

Cryptographic Failure #2: Passwords Stored Insecurely

The Failure

Passwords stored in plaintext, reversible encryption, or hashed with fast algorithms (MD5, SHA-1, SHA-256) that attackers crack in seconds.

Example

# VULNERABLE: MD5 hashing (fast, crackable)
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()
# MD5 hash of "password123": 482c811da5d5b4bc6d497ffa98491e38
# Cracked in milliseconds using rainbow tables

# VULNERABLE: SHA-256 without salt (still fast)
password_hash = hashlib.sha256(password.encode()).hexdigest()
# Crackable via GPU-accelerated brute-force at billions of hashes per second

# VULNERABLE: Plaintext storage
db.execute("INSERT INTO users (email, password) VALUES (?, ?)", (email, password))

Real-World Impact

Database breach exposes the users table. If passwords are in plaintext, every account is immediately compromised. If hashed with MD5 or SHA-256, most passwords are cracked within hours using GPU hardware. Users who reuse passwords (most users) are now compromised across every service where they used the same password.

The Fix

# SECURE: bcrypt with appropriate cost factor
import bcrypt

# Hashing
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
# bcrypt is intentionally slow: ~250ms per hash at rounds=12
# Attacker cracking rate: ~3 hashes/second vs billions with MD5

# Verification
if bcrypt.checkpw(password.encode(), stored_hash):
    # Password correct
  

// SECURE: Argon2 (Node.js)
const argon2 = require('argon2');

// Hashing
const hash = await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 65536,  // 64 MB
    timeCost: 3,
    parallelism: 4
});

// Verification
const valid = await argon2.verify(hash, password);

Acceptable algorithms: bcrypt (cost factor 12+), Argon2id (recommended for new implementations), scrypt. All three are intentionally slow and include salt automatically.

Never acceptable: MD5, SHA-1, SHA-256, SHA-512 for passwords. These are general-purpose hash functions designed for speed, making them unsuitable for password storage.

Checklist:

• Passwords hashed with bcrypt, Argon2id, or scrypt
• Cost factor/work factor set appropriately (bcrypt: 12+)
• No MD5, SHA-1, or unsalted SHA-256 for passwords
• No plaintext password storage anywhere (including logs, backups)
• Password hashing applied before storage, not after retrieval

For secure coding standards covering password handling and more, see our secure coding standards guide.

Cryptographic Failure #3: Sensitive Data Stored Unencrypted

The Failure

Sensitive data stored in databases, files, or backups without encryption at rest. If an attacker gains database access (through SQL injection, stolen credentials, or backup exposure), data is immediately readable.

Example

-- VULNERABLE: Credit card numbers stored in plaintext
CREATE TABLE payments (
    id INT PRIMARY KEY,
    user_id INT,
    card_number VARCHAR(16),    -- 4111111111111111 in plaintext
    card_expiry VARCHAR(5),     -- 12/25 in plaintext
    card_cvv VARCHAR(3)         -- 123 in plaintext (PCI DSS violation: CVV must never be stored)
);

Real-World Impact

SQL injection on a single endpoint exposes every stored credit card number. Backup tapes lost or stolen expose all data without an encryption barrier. Database administrator with access sees all sensitive data in readable form.

The Fix

# SECURE: Encrypt sensitive data before storage
from cryptography.fernet import Fernet
import os

# Key management: retrieve from KMS, never hardcode
key = get_key_from_kms('payment-data-key')
cipher = Fernet(key)

# Encrypt before storage
encrypted_card = cipher.encrypt(card_number.encode())
db.execute("INSERT INTO payments (user_id, encrypted_card) VALUES (?, ?)", 
           (user_id, encrypted_card))

# Decrypt only when needed
decrypted_card = cipher.decrypt(encrypted_card).decode()

Better approach for PCI DSS: Use tokenisation. Replace card numbers with tokens. The actual card data lives only in a PCI-compliant token vault.

Checklist:

• Sensitive data encrypted at rest in databases
• Encryption keys managed through KMS (AWS KMS, Azure Key Vault, HashiCorp Vault)
• Backups encrypted with separate keys from production
• CVV/CVC never stored after payment authorisation (PCI DSS)
• Sensitive data not stored unnecessarily (data minimisation)

For PCI DSS specific encryption requirements, see our PCI DSS penetration testing guide.

Cryptographic Failure #4: Insecure Mobile Data Storage

The Failure

Mobile applications often store sensitive information such as access tokens, refresh tokens, API keys, user identifiers, and session data on the device for convenience. On Android, developers commonly use SharedPreferences for local storage. However, SharedPreferences stores data in plaintext XML files by default. If a device is rooted, an application backup is exposed, or an attacker gains filesystem access, the stored data can be extracted and abused. Sensitive data stored without encryption at rest is a cryptographic failure.

Example

// VULNERABLE: Plaintext SharedPreferences

SharedPreferences prefs =
        getSharedPreferences("app_prefs", MODE_PRIVATE);

prefs.edit()
        .putString("access_token", accessToken)
        .putString("refresh_token", refreshToken)
        .putString("api_key", apiKey)
        .apply();

Stored preferences file:

<map>
    <string name="access_token">
        eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
    </string>
    <string name="refresh_token">
        d7f3e8c4a6...
    </string>
    <string name="api_key">
        sk_live_xxxxxxxxxxxxxxxxx
    </string>
</map>

Anyone who gains access to the application's data directory can read these values without needing to decrypt them.

Real-World Impact

An attacker extracts data from a rooted Android device or an exposed application backup. Because authentication tokens and API keys are stored in plaintext, the attacker can impersonate the user, access backend APIs, or take over active sessions without knowing the user's password. If encryption keys are also stored locally, encrypted application data can be decrypted, resulting in a complete compromise of sensitive information.

The Fix

// Add AndroidX Security Crypto

implementation "androidx.security:security-crypto:1.1.0-alpha06"

// SECURE: Encrypt SharedPreferences using Android Keystore

MasterKey masterKey = new MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build();

SharedPreferences securePrefs =
        EncryptedSharedPreferences.create(
                context,
                "secure_prefs",
                masterKey,
                EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
                EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
        );

securePrefs.edit()
        .putString("access_token", accessToken)
        .putString("refresh_token", refreshToken)
        .apply();

Instead of storing readable values, Android encrypts both preference keys and values before writing them to disk. The encryption keys are securely protected by the Android Keystore, making it significantly harder for attackers to recover sensitive data even if the application's storage is extracted.

Checklist:

• Never store passwords in SharedPreferences
• Store authentication tokens using EncryptedSharedPreferences
• Protect encryption keys with the Android Keystore
• Never hardcode API keys or encryption keys inside the APK
• Clear sensitive data during logout or account deletion
• Encrypt all sensitive data stored locally
• Disable Android backups for applications handling highly sensitive data unless backups are encrypted
• Validate local data storage during mobile application penetration testing

Cryptographic Failure #5: Weak or Obsolete Algorithms

The Failure

Using deprecated cryptographic algorithms that have known weaknesses: DES, 3DES, RC4, MD5 for integrity, SHA-1 for digital signatures, RSA with small key sizes, or custom ("homegrown") cryptographic implementations.

Example

# VULNERABLE: DES encryption (56-bit key, crackable)
from Crypto.Cipher import DES
cipher = DES.new(key, DES.MODE_ECB)  # DES + ECB mode: double failure

# VULNERABLE: MD5 for data integrity verification
import hashlib
checksum = hashlib.md5(data).hexdigest()  # Collision attacks are practical

# VULNERABLE: SHA-1 for digital signatures
signature = hashlib.sha1(document).hexdigest()  # Collision demonstrated (SHAttered)

The Fix

# SECURE: AES-256-GCM for encryption
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)
aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)

# SECURE: SHA-256+ for integrity
import hashlib
checksum = hashlib.sha256(data).hexdigest()

# SECURE: SHA-256+ for digital signatures / HMAC
import hmac
signature = hmac.new(key, message, hashlib.sha256).hexdigest()

Algorithm guidance:

Cryptographic Failure #6: Insufficient Transport Layer Security

The Failure

Supporting outdated TLS versions (1.0, 1.1), weak cipher suites, missing certificate validation, or allowing protocol downgrade attacks.

Example

# VULNERABLE: Server supports TLS 1.0 and weak ciphers
$ nmap --script ssl-enum-ciphers -p 443 target.com
| TLSv1.0:
|   ciphers:
|     TLS_RSA_WITH_RC4_128_SHA - WEAK
|     TLS_RSA_WITH_DES_CBC_SHA - WEAK
| TLSv1.1:
|   ciphers:
|     TLS_RSA_WITH_3DES_EDE_CBC_SHA - WEAK

Real-World Impact

Downgrade attacks force connections to weak TLS versions. POODLE, BEAST, and CRIME attacks exploit TLS 1.0 weaknesses. Weak ciphers allow passive decryption of captured traffic.

The Fix

# SECURE: Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;  # Let client choose with TLS 1.3
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

Checklist:

• TLS 1.0 and 1.1 disabled
• TLS 1.2 minimum, TLS 1.3 preferred
• No RC4, DES, 3DES, NULL, or export cipher suites
• Forward secrecy enabled (ECDHE cipher suites)
• HSTS deployed with preload
• Certificate chain valid and trusted
• Certificate expiration monitored

Cryptographic Failure #7: Inadequate JWT Security

The Failure

JSON Web Tokens with weak signing secrets, missing algorithm validation, no expiration, or the "none" algorithm accepted.

Example

# VULNERABLE: Weak JWT secret (brute-forceable)
token = jwt.encode(payload, "secret123", algorithm="HS256")
# "secret123" cracked in seconds with tools like jwt_tool or hashcat

# VULNERABLE: No algorithm validation on verification
decoded = jwt.decode(token, key, algorithms=["HS256", "none"])
# Attacker changes header to {"alg": "none"} and removes signature

# VULNERABLE: No expiration
payload = {"user_id": 123, "role": "admin"}
# Token valid forever once issued

The Fix

# SECURE: Strong secret + algorithm enforcement + expiration
import jwt
import datetime
import secrets

# Strong secret (256+ bits of entropy)
JWT_SECRET = secrets.token_hex(32)  # 256-bit key

# Encode with expiration
payload = {
    "user_id": 123,
    "role": "user",
    "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1),
    "iat": datetime.datetime.utcnow()
}
token = jwt.encode(payload, JWT_SECRET, algorithm="HS256")

# Decode with explicit algorithm validation
decoded = jwt.decode(token, JWT_SECRET, algorithms=["HS256"])
# Rejects "none" algorithm and any algorithm not in the list

Better approach: Use asymmetric algorithms (RS256, ES256) where the signing key and verification key are different, preventing key confusion attacks.

JWT vulnerabilities are a primary focus during API security testing and API penetration testing.

How Penetration Testing Discovers Cryptographic Failures

Automated scanners detect some cryptographic failures (weak TLS, missing HSTS). But most cryptographic failures require manual penetration testing that examines how the application actually handles sensitive data.

What Testers Check

Transport security. TLS version and cipher suite analysis on all endpoints. HSTS presence and configuration. Certificate validity. Mixed content issues. Internal service communication encryption.

Authentication cryptography. Password hashing algorithm identification. JWT implementation security (secret strength, algorithm validation, expiration). Session token randomness and entropy.

Data storage. Whether sensitive data is encrypted at rest. Encryption algorithm strength. Key management practices. Database encryption configuration.

Secret management. Hardcoded secrets in source code, configuration files, and client-side code. API keys in URLs or client-side JavaScript. Secrets in version control history.

Error handling. Whether error messages expose cryptographic implementation details, internal keys, or decrypted data.

Testing Within VAPT Engagements

Cryptographic failure testing is a standard component of VAPT (Vulnerability Assessment and Penetration Testing). Vulnerability assessment identifies missing encryption and weak configurations automatically. Penetration testing validates the impact: can an attacker actually access, decrypt, or crack the exposed data?

The VAPT process ensures both breadth (automated discovery of cryptographic weaknesses) and depth (manual exploitation proving business impact).

Testing Across Application Types

Web applications. Web application penetration testing covers the full OWASP Top 10 including A02 Cryptographic Failures. Testing evaluates password storage, session security, TLS configuration, and sensitive data handling. See our guide on common web application security vulnerabilities.

APIs. API penetration testing and API security testing evaluate JWT implementation, API key management, transport encryption, and sensitive data exposure in API responses.

Cloud infrastructure. Cloud penetration testing evaluates encryption at rest (storage, databases, volumes), encryption in transit, and key management through cloud KMS.

Cryptographic Failures and Compliance

Cryptographic failures directly violate requirements across major compliance frameworks.

PCI DSS

Requirement 3 mandates protection of stored cardholder data through encryption, truncation, masking, or hashing. Requirement 4 mandates encryption during transmission over public networks. Weak encryption, missing encryption, or poor key management are PCI DSS audit failures. See our PCI DSS penetration testing guide.

SOC 2

Trust Services Criteria CC6.1 (Logical and Physical Access Controls) and CC6.7 (Encryption) require that data is protected through cryptographic controls during transmission and storage. Cryptographic failures in SOC 2 in-scope systems create audit findings. See how SOC 2 pentests support compliance.

ISO 27001

Annex A.8.24 (Use of Cryptography) requires that cryptographic controls are implemented appropriately. Annex A.8.9 (Configuration Management) requires secure configuration of encryption. See our ISO 27001 guide.

HIPAA

The Security Rule requires encryption of ePHI in transit (§164.312(e)(1)) and considers encryption at rest an addressable safeguard (§164.312(a)(2)(iv)). Cryptographic failures exposing health data create HIPAA violations. See our healthcare penetration testing guide.

GDPR

Article 32(1)(a) specifically mentions encryption as an appropriate technical measure for data protection. Cryptographic failures enabling personal data exposure violate GDPR's security requirements. See our GDPR penetration testing guide.

Complete Cryptographic Failures Prevention Checklist

Transport Security

• HTTPS enforced on all endpoints
• HSTS deployed with minimum 1-year max-age
• TLS 1.2+ only (1.0 and 1.1 disabled)
• Strong cipher suites only (forward secrecy enabled)
• Internal service communication encrypted
• Database connections use TLS

Password Storage

• Passwords hashed with bcrypt (12+), Argon2id, or scrypt
• No MD5, SHA-1, or unsalted SHA-256 for passwords
• No plaintext passwords anywhere

Data at Rest

• Sensitive data encrypted in databases
• Encryption keys in KMS (not in code)
• Backups encrypted with separate keys
• CVV never stored post-authorisation

Secrets Management

• No secrets in source code
• Pre-commit hooks detect secrets
• Secrets from secrets manager at runtime
• Keys rotated on defined schedule

JWT and Tokens

• JWT secrets 256+ bits of entropy
• Algorithm explicitly validated (no "none")
• Token expiration enforced
• Asymmetric signing for high-security use cases

Algorithms

• No DES, 3DES, RC4, Blowfish
• AES-256-GCM for symmetric encryption
• RSA-2048+ or ECDSA P-256+ for asymmetric
• SHA-256+ for integrity and signatures
• No custom/homegrown cryptography

Data Handling

• No sensitive data in URL parameters
• API keys in headers, not URLs
• Sensitive data masked in logs
• Error messages don't expose cryptographic details

How AppSecure Identifies Cryptographic Failures

AppSecure's penetration testing systematically evaluates every cryptographic control protecting your sensitive data.

OWASP Top 10 Coverage

Every web application assessment covers A02 Cryptographic Failures alongside the full OWASP Top 10. Testers evaluate password storage, transport security, data encryption, secret management, and JWT implementation.

API Cryptographic Testing

API penetration testing and API security testing evaluate authentication token security, API key management, transport encryption, and sensitive data exposure in responses.

VAPT Integration

AppSecure's VAPT process combines automated scanning (catching weak TLS, missing encryption, known CVEs) with manual testing (validating password hash strength, testing JWT implementation, proving data exposure impact).

Compliance Mapping

Reports map cryptographic findings to PCI DSS, SOC 2, ISO 27001, HIPAA, and GDPR requirements. One assessment provides compliance evidence across frameworks.

Zero False Positives. Every cryptographic finding is validated with evidence. Your team fixes confirmed weaknesses, not theoretical concerns.

3-Week Delivery. 90-day remediation support and complimentary retesting. Continuous penetration testing and PTaaS maintain ongoing validation. Application security assessment and offensive security testing provide comprehensive coverage.

Ready for testing that finds the cryptographic failures scanners miss?

Contact AppSecure:

• Schedule Application Security Testing
• Web Application Penetration Testing
• Application Security Assessment

Frequently Asked Questions

1. What are cryptographic failures (OWASP A02)?

Cryptographic failures occur when applications fail to adequately protect sensitive data through cryptography. This includes data transmitted without encryption (HTTP instead of HTTPS), passwords stored with weak hashing (MD5, SHA-1), sensitive data stored unencrypted in databases, hardcoded encryption keys in source code, weak or obsolete cryptographic algorithms, insecure JWT implementations, and sensitive data exposed in URLs or logs. OWASP ranks cryptographic failures #2 in the Top 10 because they directly enable data breaches affecting passwords, financial data, health records, and personal information.

2. Why did OWASP rename "Sensitive Data Exposure" to "Cryptographic Failures"?

The rename in the 2021 OWASP Top 10 shifted focus from the symptom (data got exposed) to the root cause (cryptography was absent, weak, or improperly implemented). Every sensitive data exposure traces back to a cryptographic failure. The new name guides developers toward fixing the cause rather than just recognising the consequence. The category was also elevated from #3 to #2, reflecting its prevalence and impact.

3. What is the most common cryptographic failure?

Insecure password storage is the most commonly found cryptographic failure during penetration testing. Organisations storing passwords with MD5, SHA-1, or unsalted SHA-256 allow attackers who breach the database to crack most passwords within hours. The fix is using bcrypt, Argon2id, or scrypt, which are intentionally slow algorithms that make brute-force cracking computationally expensive. The second most common failure is missing or incomplete HTTPS enforcement.

4. How do penetration testers find cryptographic failures?

Testers evaluate TLS version and cipher suites on all endpoints, test password hashing by creating accounts and analysing stored hashes (or testing for timing differences), assess JWT implementation (secret strength, algorithm validation, expiration), check for hardcoded secrets in client-side code and API responses, test whether sensitive data appears in URLs or logs, validate encryption at rest for databases and storage, and assess error handling for cryptographic detail exposure. Manual testing discovers failures automated scanners miss: weak JWT secrets, application-level encryption misuse, and secret exposure in non-obvious locations.

5. Which compliance frameworks address cryptographic requirements?

PCI DSS (Requirements 3 and 4: encryption of stored and transmitted cardholder data), SOC 2 (CC6.1 and CC6.7: logical access and encryption), ISO 27001 (Annex A.8.24: Use of Cryptography), HIPAA (§164.312: encryption of ePHI in transit and at rest), and GDPR (Article 32(1)(a): encryption as an appropriate technical measure). Cryptographic failures create compliance violations across all these frameworks. Penetration testing identifies these failures with evidence that maps to specific compliance requirements.

6. What hashing algorithms should be used for passwords?

Use bcrypt (cost factor 12+), Argon2id (recommended for new implementations), or scrypt. These are purpose-built password hashing algorithms that are intentionally slow, include automatic salting, and resist GPU-accelerated cracking. Never use MD5, SHA-1, SHA-256, or any general-purpose hash function for passwords. General-purpose hashes are designed for speed, meaning attackers can test billions of password candidates per second.

7. What TLS configuration is considered secure?

TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0 and 1.1 entirely. Use only cipher suites with forward secrecy (ECDHE). Remove RC4, DES, 3DES, NULL, and export cipher suites. Enable HSTS with a minimum one-year max-age. Deploy OCSP stapling. Monitor certificate expiration. Test your configuration with tools like SSL Labs or testssl.sh.

8. How do I prevent hardcoded secrets?

Store secrets in dedicated secrets managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault). Never commit secrets to source code or configuration files. Add .env and key files to .gitignore. Deploy pre-commit hooks (gitleaks, truffleHog) that scan for secrets before code reaches the repository. Automate key rotation. If secrets are found in version control history, rotate them immediately as the history is permanent.

9. Are cryptographic failures detected by automated scanners?

Partially. Automated scanners detect some cryptographic failures: weak TLS versions, missing HSTS, known-vulnerable cipher suites, and missing encryption headers. However, scanners cannot assess password hashing algorithm strength, evaluate JWT implementation security, discover hardcoded secrets in application logic, or test whether encryption at rest is properly implemented in databases. Manual penetration testing is required for comprehensive cryptographic failure assessment.

10. What is the business impact of cryptographic failures?

Cryptographic failures directly enable data breaches. Passwords stored insecurely lead to mass account compromise. Credit card data stored unencrypted leads to PCI DSS violations and financial fraud. Health records exposed through missing encryption lead to HIPAA penalties. Personal data exposed through transport security failures leads to GDPR fines. Beyond regulatory penalties, cryptographic failures damage customer trust, trigger breach notification obligations, and create litigation exposure. The average data breach costs $4.88 million globally, and cryptographic failures are a leading root cause.