Password Security Patterns
This document serves as a knowledge base and learning resource on the best security practices applied in password recovery flows, using as a reference an architecture based on [[Flet]] and [[Hexagonal Architecture]]. In archi...
Security Patterns: Password Recovery and Endpoints
This document serves as a knowledge base and learning resource on best practices for security applied in password recovery flows, using a reference architecture based on [[Flet]] and [[Hexagonal Architecture]].
1. The Myth of GET Endpoints in Flet
In traditional architectures (such as a PHP MVC or traditional server-side rendering), sending a form with sensitive data through a HTTP GET endpoint is a critical vulnerability, as the password would be exposed in the URL (e.g., /api/change?pwd=secreta), being stored in server logs and browser history.
Why this doesn't apply to Flet for the submit:
- Flet is a framework that communicates through WebSockets.
- The Token in the GET: It is completely standard and secure that the link sent by email contains the token in the URL (e.g.,
/reset-password?token=abc...). This is necessary for the link to be "clickable". - The Submit (POST equivalent): When the user enters the new password in the Flet UI and presses "Save", Flet does not make an HTTP GET request. It packages the UI input and transmits it through the secure tunnel (WSS - WebSocket Secure) to the backend (
AuthController). The new password is never exposed in the URL or in web routing logs.
2. Hexagonal Architecture and Resend API
For sending emails, it is essential not to couple the authentication controller with the third-party library (in this case, the Resend API).
Correct Implementation:
- Define a Protocol (Interface): Create an abstract
EmailService(Protocol). - Implement the Adapter: Create a
ResendEmailServicethat implements that interface and integrates the official SDK. - Dependency Injection: The domain service (
AuthService) only knows the protocol, ignoring whether Resend, SendGrid, or a Mock is behind it, for testing purposes.
Related: [[Hexagonal Architecture]], [[Dependency Injection]], [[Protocol]]
3. Advanced Security Practices (Zero Technical Debt)
When auditing authentication flows [[Authentication]], the absence of technical debt becomes evident when implementing these three shields:
A. Protection against Email Enumeration
- The Problem: If the API returns "Email not found" when an attacker enters a random email, and "Email sent" when the email is real, the attacker can discover which users are registered on the platform.
- The Solution: The
request_password_resetendpoint/method should always return a generic message, regardless of whether the user exists or not in the database (e.g., "If your email is registered, you will receive a link to reset your password").
B. Atomic Token Consumption (TOCTOU Prevention)
- The Problem (Time-Of-Check to Time-Of-Use): If you first make a
SELECTto verify that the token is valid, and then an UPDATE to change the password, two concurrent requests milliseconds apart could bypass the verification and use the token twice. - The Solution: Use an atomic operation at the database level (
UPDATE ... RETURNING). Claim and invalidate the token in a single SQL transaction. If theUPDATEfails, the token already consumed or does not exist.
C. End-to-End Rate Limiting
- Limit the number of requests not only in login, but also in the endpoint that generates the reset tokens. This prevents denial-of-service (DoS) attacks where an attacker tries to exhaust the quota of the Resend API or saturate the server with spam emails.
Related Concepts:
- [[Web Security]]
- [[TOCTOU Prevention]]
- [[Rate Limiting]]