🚀 Join our AI Wargame at Black Hat Asia and our Workshop + Wargame at NDC Sydney .


Weak Credentials

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

Open Csharp labs in SecDim Play for this vulnerability.

Deco line
Deco line

Play AppSec WarGames

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.

Deco line
Deco line

Got a comment?

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.

Read more