Skip to content
Flag of Europe
Made in the European Union · Independently built · Released under EUPL 1.2
Compliance & CWE Coverage

Compliance & CWE Coverage

Covers the credential-security stack shipped in 00.72.00 (the credential layer introduced in the 00.71 milestone). “Coverage” means risk reduction / mitigation — a weakness class is rarely eliminated by a single feature, but reduced and made manageable by a cluster of implementation features, tests, operating rules and documentation.

jSentinel’s credential layer is designed against three reference frameworks, with an explicit traceability artifact for each:

StandardScopeWhere it shows up
OWASP ASVS V2 (Authentication)Verification requirements for credential storage, lifecycle and recoveryPer-control mapping in the repo’s credential/standards package
NIST SP 800-63BMemorised-secret rules: length, breached-password checks, no composition rules, rate limitingInput policy, compromised-password checker, abuse detection
CWE (MITRE)40 concrete weakness classesFull matrix below

Threat-vector coverage

The credential layer is built bottom-up from a catalogue of concrete attacks. Each row is countered by a cluster of features — most measures raise the cost of an attack or prevent a specific exploitation rather than guaranteeing absolute security.

CategoryAttack vectorCountered by
Offline hash attacksOffline brute-force / dictionaryMemory-hard KDF (Argon2id / scrypt), per-hash salt, pepper, high PBKDF2 iteration floor
GPU / ASIC / FPGA crackingArgon2id / scrypt memory-hardness
Rainbow tables / precomputationPer-credential random salt
DB leak without the pepperPost-KDF HMAC pepper held separately from the hash DB
Stale, un-upgraded parametersRehash-on-verify with deterministic precedence
Format / algorithm tamperingAlgorithm downgrade / silent fallbackFail-fast when the modern profile’s provider is absent (no silent downgrade)
Forged / unknown algorithm idSelf-describing envelope + strict parameter validators
Format confusion / forward-incompatVersioned $pwh$v=1$… envelope, rejected-version policy
Resource / DoSKDF resource exhaustionKdfExecutionLimiter (concurrency + wait budget)
Crafted-parameter “decompression bomb”Parameter bounds validated before any KDF; memory cost overflow-checked
Online login attacksOnline brute-forceAbuse detection + LoginAttemptPolicy + rate limiting
Credential stuffingCompromised-password check, abuse detection, multi-dim sliding window
Password sprayingGlobal / tenant sliding-window spraying detector
Enumeration & side channelsAccount enumeration (response + timing)verifyAgainstNothing dummy KDF, generic perimeter responses
Timing side channel on compareConstant-time MessageDigest.isEqual
Tenant enumerationGeneric public errors, no tenant leak
Password qualityWeak / guessable passwordsInput policy, breached-password blocklist + HIBP
Context-trivial passwordContextAwarePasswordValidator (username / email / term overlap)
Reuse on changeOptional PasswordHistoryService
bcrypt-specific72-byte truncationExplicit rejection, no silent pre-hashing
Password shuckingSame — no upstream unsalted hash
Reset / recoveryReset-token guessing16-byte selector + 32-byte verifier from SecureRandom
Reset-token DB theftDigest-only storage (selector/verifier model)
Reset-token replaySingle-use via dual compare-and-swap
Reset abuse / mail-bombing / enumerationGeneric responses + abuse detection on the reset flow
Credential lifecycleAccount takeover via password change w/o re-authMandatory re-authentication in PasswordChangeService
Lingering sessions after compromise/changeINVALIDATE_OTHER_SESSIONS default
Persistence / concurrencyRace condition / lost update (TOCTOU)Compare-and-swap on every credential mutation
Migration blind-overwriteCAS witness (originalEncodedHash) on rehash
Secret exposureSecret leak via logs / toString() / heapSecretValue (AutoCloseable), redacted toString, zeroed buffers
Secret / token leak via audit / errorsAudit-only internal types, perimeter-safe public types
Supply chain / crypto trustCompromised crypto provider or JDKFIPS profile, JDK distribution trust, SBOM, PKCS#11 HSM docs
Weak / subverted randomnessSecureRandom throughout
Operations / configTest / weak parameters in productionParameter validators reject out-of-range; calibration never auto-runs
No emergency responseEmergency playbooks + EmergencyPolicyOverride + MassCredentialStatusChange

CWE coverage matrix

The credential layer addresses 40 CWE weakness classes. The counts below are the number of features that directly cover each weakness, plus supporting features (tests, governance, operating rules). This is the condensed view; the full per-feature breakdown (166 features across 19 epics) lives in the project repository.

CWETitleDirectSupporting
CWE-16Configuration20
CWE-20Improper Input Validation83
CWE-200Exposure of Sensitive Information to an Unauthorized Actor150
CWE-203Observable Discrepancy111
CWE-208Observable Timing Discrepancy31
CWE-209Generation of Error Message Containing Sensitive Information70
CWE-223Omission of Security-relevant Information33
CWE-256Plaintext Storage of a Password10
CWE-257Storing Passwords in a Recoverable Format30
CWE-284Improper Access Control101
CWE-287Improper Authentication254
CWE-306Missing Authentication for Critical Function50
CWE-307Improper Restriction of Excessive Authentication Attempts153
CWE-312Cleartext Storage of Sensitive Information120
CWE-321Use of Hard-coded Cryptographic Key101
CWE-325Missing Cryptographic Step112
CWE-326Inadequate Encryption Strength80
CWE-327Use of a Broken or Risky Cryptographic Algorithm358
CWE-330Use of Insufficiently Random Values52
CWE-338Use of Cryptographically Weak Pseudo-Random Number Generator42
CWE-362Race Condition91
CWE-367Time-of-check Time-of-use Race Condition91
CWE-400Uncontrolled Resource Consumption143
CWE-521Weak Password Requirements142
CWE-522Insufficiently Protected Credentials507
CWE-532Insertion of Sensitive Information into Log File80
CWE-613Insufficient Session Expiration20
CWE-620Unverified Password Change30
CWE-639Authorization Bypass Through User-Controlled Key20
CWE-640Weak Password Recovery Mechanism for Forgotten Password131
CWE-759Use of a One-Way Hash without a Salt12
CWE-760Use of a One-Way Hash with a Predictable Salt11
CWE-770Allocation of Resources Without Limits or Throttling91
CWE-778Insufficient Logging136
CWE-798Use of Hard-coded Credentials30
CWE-829Inclusion of Functionality from Untrusted Control Sphere61
CWE-863Incorrect Authorization40
CWE-916Use of Password Hash With Insufficient Computational Effort217
CWE-1104Use of Unmaintained Third Party Components41
CWE-1240Use of a Cryptographic Primitive with a Risky Implementation31

The three highest-coverage weakness classes — CWE-522 (Insufficiently Protected Credentials, 50 features), CWE-327 (Broken / Risky Crypto, 35) and CWE-287 (Improper Authentication, 25) — are exactly the core of credential security, which is where this layer concentrates.

How a control maps end-to-end

A worked example for CWE-916 (Use of Password Hash With Insufficient Computational Effort):

  1. Default — PBKDF2 at the OWASP-2023 floor (600 000 iterations) in JDK-only security-core.
  2. Modern profile — Argon2id (t=3, m=64 MiB, p=1) via the opt-in security-crypto-bc module.
  3. No silent downgrade — requesting the modern profile without the provider on the classpath fails fast (CWE-693).
  4. Crypto-agilityRehashDecision upgrades hashes on next login when parameters fall behind policy.
  5. Resource controlKdfExecutionLimiter bounds concurrent KDF work so the strong parameters can’t be turned into a DoS (CWE-400).

That is five distinct features cooperating on one weakness class — the pattern the matrix above counts.

Caveats

  • Not every vector is closed by the credential layer alone. Session management, brute-force lockout and throttling lean on SessionPolicy, LoginAttemptPolicy and LogoutService — the credential features supply the signals and interfaces, not the full implementation.
  • Several controls are SPIs: they take effect only once the application provides an implementation — e.g. the atomic CredentialStore (depends on your persistence layer) and abuse detection (needs a shared counter/event store in distributed deployments).
  • The full per-feature justification (166 rows, German) is maintained in the repository under docs/v00.71.00/.