Loading published curriculum…

16 · Spring Security in depth / LESSON 84 OF 102

Rate limits, reset tokens, and security review

Secure authentication also needs controls for repeated abuse and credential recovery.

Before this lesson: OAuth2, OIDC, and JWT resource servers

Understand the topic

Bound login and reset attempts using an appropriate shared store or gateway policy. Local in-memory limits reset on restart and do not coordinate replicas. Use generic recovery responses, short-lived one-time tokens, and atomic token consumption.

Keep an audit trail of security-relevant events without raw passwords or tokens. Review dependency advisories, secret exposure, ownership checks, and public error content. Validate every recovery and administrative path, not only normal login.

EXAMPLE · JAVA

Reset-token generation fragment

byte[] bytes = new byte[32];
new java.security.SecureRandom().nextBytes(bytes);
String token = java.util.Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
byte[] storedHash = java.security.MessageDigest.getInstance("SHA-256")
 .digest(token.getBytes(java.nio.charset.StandardCharsets.UTF_8));

What to expect

Store a hash, expiry, and account reference; deliver the raw token only through the intended recovery channel. Atomically consume the stored record on use. This is token generation, not a complete reset flow.

YOUR TURN

Put it into practice

  1. 01Implement expiring single-use reset tokens and bounded reset attempts.
  2. 02Race two uses of the same token and test expired and random tokens.
  3. 03Verify: At most one reset succeeds and logs never contain raw credentials or recovery tokens.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Secure authentication also needs controls for repeated abuse and credential recovery.

  1. 01Bound login and reset attempts using an appropriate shared store or gateway policy. Local in-memory limits reset on restart and do not coordinate replicas. Use generic recovery responses, short-lived one-time tokens, and atomic token consumption.
  2. 02Keep an audit trail of security-relevant events without raw passwords or tokens. Review dependency advisories, secret exposure, ownership checks, and public error content. Validate every recovery and administrative path, not only normal login.
  3. 03Trace the example: Store a hash, expiry, and account reference; deliver the raw token only through the intended recovery channel. Atomically consume the stored record on use. This is token generation, not a complete reset flow.

A mistake worth avoiding

The same reset link can change the password repeatedly.

DEBUGGING ROOM

Something broke. Where do you look?

The same reset link can change the password repeatedly.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Can a per-process rate limiter coordinate limits across several replicas?

Choose one answer

BUILD IT YOURSELF

Implement expiring single-use reset tokens and bounded reset attempts.

  1. 1.Implement expiring single-use reset tokens and bounded reset attempts.
  2. 2.Race two uses of the same token and test expired and random tokens.
  3. 3.Reproduce this failure, then repair it: The same reset link can change the password repeatedly.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Can a per-process rate limiter coordinate limits across several replicas?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

At most one reset succeeds and logs never contain raw credentials or recovery tokens.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references