A secure password recovery process

Balancing account recovery with verification

I led research and design for a password recovery process on a SaaS payment platform. The goal was to help users regain access without calling Customer Support while establishing an appropriate verification step before a password could be changed. Working with Product and Security, I developed a flow centered on phone-code verification.

Comparing convenience with reliance on email

I audited recovery flows on platforms including Amazon, Google, and Facebook to compare their steps and security measures. A common pattern was to email a unique reset link: a convenient route that avoided asking users to copy or remember a temporary code.

That convenience raised a design question for our platform. If access to an email inbox was enough to reset the password, a compromised inbox could also expose the payment account. I used the email-based flow as a baseline for evaluating an alternative verification route.

Requiring verification before changing the password

We selected a flow that asked users to identify their account, validate a temporary code delivered to their phone, and then create a new password. The diagram allowed for delivery by text message or voice call; the interface concept focused on SMS.

The trade-off was additional effort. Users had to retrieve and enter a code instead of opening a link. We accepted that friction to make phone verification a prerequisite for changing the password, while recognizing that the approach did not eliminate every account-recovery risk.

Giving useful guidance without confirming account existence

At the account-identification step, the intended behavior was to avoid disclosing whether a submitted username or email address was valid. This limited feedback for legitimate users, but also limited what that response could reveal about who held an account.

For code entry, the design explained where to look for the message and provided a resend action. For password creation, it placed requirements alongside the input and included a visibility control so users could inspect what they entered.

I also reviewed research on password-strength meters when considering password guidance. Its findings depended on context, so it informed the design exploration rather than establishing that this particular interface would produce stronger passwords.

Aligning the flow across Product, Security, and Design

I worked with the product manager to bring Product, Security, and Design into decisions about recovery. The work defined the proposed flow and its interface states, from requesting recovery through confirmation. Reducing support calls remained a project goal; this case study does not document a measured reduction or confirm production rollout.

What I would validate earlier

I would involve key stakeholders earlier. Technical discussions led to repeated revisions of the proposed flows, and earlier alignment could have reduced that back-and-forth.

I would also examine the limits of phone-based verification more deeply. Email and SMS can be accessible on the same smartphone, so access to that device could undermine the separation I was relying on. This remained an unresolved concern rather than a risk the design could claim to have removed.

Finally, some decisions drew on informal observations of social-platform users and assumptions from those observations. I did not conduct formal tests with representative users. Those tests would have been important for evaluating comprehension, code-entry friction, and the recovery flow as a whole.