The use of weak, easily guessable, or default cryptographic keys significantly increases the risk of unauthorised access and security bypass. For example, if a JSON Web Token (JWT) signing key is weak, an adversary can brute-force or guess the key, forge tokens, and gain authenticated access. Similarly, default or hard-coded keys embedded in applications expose systems to compromise if discovered.
Remediation
Always generate cryptographic keys using a cryptographically secure random number generator (CSPRNG).
Use strong key sizes appropriate for the algorithm: at least 256-bit keys for symmetric algorithms (e.g., AES, HMAC) and at least 2048-bit keys for RSA (3072-bit recommended for long-term security).
Regularly rotate keys and immediately revoke compromised or suspected weak keys.
Never ship software with default, static, or hard-coded keys; enforce secure key management practices (e.g., KMS, HSM, or vault solutions).
Apply strict access controls around key storage to minimise exposure.
Metadata
Severity: high
Slug: weak-credentials
CWEs
798: Use of Hard-coded Credentials
1392: Use of Default Credentials
257: Storing Passwords in a Recoverable Format
338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
331: Insufficient Entropy
OWASP
A02:2021: Cryptographic Failures
A07:2021: Identification and Authentication Failures
Available Labs
Select a language to explore available labs for this vulnerability.
Want to skill-up in secure coding and AppSec?
Try SecDim Wargames to learn how to find, hack
and fix security vulnerabilities inspired by real-world incidents.
Join our secure coding and AppSec community.
A discussion board to share and
discuss all aspects of secure
programming, AppSec, DevSecOps,
fuzzing, cloudsec, AIsec
code review, and more.
