WebOTG-CR-001 — Cryptographic Failures Review

Objective

Cryptographic failures occur when an application does not adequately protect information that requires confidentiality, integrity, authenticity or non-repudiation.

The review should cover more than simply checking whether HTTPS is enabled. It should consider data classification, encryption at rest and in transit, algorithms, protocols, certificates, password storage, secret handling, key generation, key storage, rotation and lifecycle management.

Scope

Review cryptographic protection across:

Prerequisites

Methodology

The assessment should begin with the information being protected rather than with a particular cryptographic algorithm.

Test procedure

Sensitive data protection

The organization should explicitly identify information that requires protection. Cryptographic requirements should then be derived from the sensitivity and security requirements of that information.

Cryptographic mechanism review

Example of an insecure implementation

// Example only

$passwordHash = md5($password);

// Hardcoded encryption key
$key = "my-secret-key";

// Sensitive data transmitted without transport protection
http://example.invalid/api/account

Transport security

Verify that sensitive information is protected while crossing untrusted or partially trusted networks.

Example request

GET /account/profile HTTP/2
Host: application.example
Cookie: [redacted]

Response:
HTTP/2 200
Content-Type: application/json

Cryptographic key management

Strong algorithms cannot compensate for poor key management. Review the entire lifecycle of cryptographic keys.

Example secret exposure

ENCRYPTION_KEY="production-secret-key"
API_TOKEN="production-api-token"
DATABASE_PASSWORD="production-password"

Assessment

Failure criteria

Remediation

Remediation should address both the cryptographic mechanism and the surrounding key-management process.

1. Identify and classify all sensitive information.
2. Map where sensitive information is transmitted, processed and stored.
3. Define cryptographic requirements for each relevant data class.
4. Use current, well-reviewed cryptographic algorithms and protocols appropriate to the use case.
5. Use established platform or library cryptographic APIs rather than implementing cryptographic primitives manually.
6. Store passwords using an appropriate password hashing or password-based key derivation mechanism.
7. Protect cryptographic keys independently from the encrypted data where the architecture requires it.
8. Remove hardcoded production secrets from source code.
9. Restrict secret and key access using least privilege.
10. Establish key rotation and revocation procedures.
11. Protect sensitive network communication using appropriately configured secure transport.
12. Review backups, logs, exports and temporary storage for unintended exposure.

Example remediation pattern

// Do not embed production secrets directly in source code.

// Application retrieves the required secret from an
// approved secret-management mechanism at runtime.

$encryptionKey = $secretManager->get("application/encryption-key");

// Use the key only for its intended purpose.
// Do not log or expose the key.

Verification

Evidence requirements

Classification

References

WebOTG should maintain authoritative source URLs, document versions and review dates through its content management system so that references can be updated without modifying the procedure structure.