Password recovery is a high-risk moment for identity abuse.
Teams need a way to let legitimate users regain access without making recovery flows easy to guess, reuse, or social engineer.
This demo uses a two-step email verification flow with OTP for account creation, password recovery, and user deletion.
Teams need a way to let legitimate users regain access without making recovery flows easy to guess, reuse, or social engineer.
It shows how email verification, password checks, and controlled recovery steps can reduce risk while still keeping the process understandable for users.
OWASP treats insecure authentication and identity recovery paths as high-value attack surfaces in API security.
This demo shows why OTP expiry, password checks, and controlled recovery steps matter when users need access restored safely.
OWASP notes that poor logging, monitoring, and authentication controls can let malicious activity persist long enough to cause serious damage.
Sources: OWASP API Security Top 10, OWASP A09:2021
This demo is a reference implementation designed to illustrate practical security choices in an AWS serverless architecture. It is intentionally simplified, but it maps directly to the AWS Well-Architected Security Pillar across identity, data protection, detection, infrastructure protection, incident response, and application security.
Each sensitive action follows a zero-trust mindset: requests are treated as untrusted by default, and the design aims to support least-privilege access with narrow request boundaries to reduce exposure of sensitive data.
OTP is used to verify email ownership and as an additional verification step alongside the password for sensitive actions such as login and deletion. Passwords are required for login, account creation, and deletion.
Request IDs are logged to support traceability without exposing secrets, and the logging pattern can be extended to CloudWatch alerting for anomaly detection.
The architecture is fully serverless and uses strict API boundaries, along with restrictive CORS, to reduce unnecessary attack surface. The backend is stateless, with no application server persisting runtime state between invocations.
Secrets are hashed with one-way cryptographic functions before being stored in the database, reducing exposure if storage is accessed by authorized operators. Transport security is enforced with TLS 1.3+ to protect data in transit. Query parameters are URL-encoded for correctness, while confidentiality in transit is provided by TLS.
OTP expiry, clear failure states, and controlled delete flows support safe recovery and response.
User input is validated on the client side before being sent to the API. Strict CORS helps limit which browser origins can call the API, but backend validation remains the primary security control.
This is a demo, not a production service. It intentionally highlights both strengths and trade-offs, including client-side compromise, email-based OTP limitations, static secret questions, cloud-provider dependency, and jurisdictional data considerations.
This page was created through a human-led process, with AI used for polishing, wording refinement, and presentation assistance. The core product thinking, architecture decisions, security analysis, and overall design direction are human-authored.
It keeps the workflow simple to understand, shows security as a deliberate design choice, and demonstrates how AWS serverless services can support a secure, explainable identity flow.
Even with TLS 1.3+, secrets can still be exposed if the client device is compromised by malware, remote access tools, or keyloggers.
OTP via email is only effective if the attacker does not already control the victim’s email account or device session.
Static secret questions can be vulnerable to social engineering. Requiring three correct answers reduces risk, but does not eliminate it.
Using Lambda, DynamoDB, and API Gateway improves operational simplicity and elasticity, but introduces some cloud-provider lock-in compared with container-based portability.
The demo keeps data collection minimal and uses a consent-driven flow, but production deployments should still consider regional jurisdiction, retention, and compliance requirements.