java-authentication-security
Java Authentication Security
Existing Authentication Boundary
Inspect the installed Spring Security version, authentication mechanism, identity provider, session/token model, credential policy and error contracts. Reuse maintained framework/provider capabilities rather than implementing replacement authentication filters, password algorithms, or token verification. Do not add local passwords to an OIDC/passkey/provider-managed application merely because this skill covers them.
Keep framework identity and servlet/session mechanisms at security/web boundaries. Adapt actor identity to an application-owned value where application operations need it. Use java-spring-security for capabilities and object scope; use java-logging-exceptions for security-event handling and secret exclusion.
Read password policy and migration when password acceptance, encoding, or legacy credentials change. That reference owns policy choices and Java length/encoder pitfalls; do not mechanically copy a PHP policy or retrofit new-password rules onto login.
Login And Attack Protection
- Use established authentication providers and password encoders. For account-sensitive credential failures, keep public output consistent for unknown, wrong-password, disabled and otherwise non-authenticating accounts unless an explicit product/security contract provides another safe flow.
- Keep internal reasons available to security events without exposing them through responses. Preserve comparable real-or-dummy credential verification on unknown-account paths using existing framework/provider behavior; do not add a second hash operation when the provider already supplies protection.
- Limit automated attempts with trusted client and account signals. Obtain client addresses through trusted-proxy handling and use approved keyed pseudonymous account keys instead of raw login identifiers. Include unknown identifiers without revealing account existence.
- Use bounded backoff or temporary lockout, recovery paths, and explicit behavior when required limiter state is unavailable; do not silently remove mandatory protection or introduce attacker-triggered permanent account lockout. CAPTCHA is supplementary.
- Apply attack protection to recovery and verification issuance as appropriate. Avoid synchronous notification differences that reveal account existence. Use established async delivery only where the actual contract requires it.