I was noticing an alarming number of people not knowing their password, yet trying to use the password reset tool designed for users who actually know their current credentials.
The situation was becoming problematic: users would attempt to reset passwords without any knowledge of their current password, this tool should only be used when you know your current credentials
Visual Example
This is the visual example of the page working before you get to the password reset tool, this is the confirmation below:
If you answer "yes" for a second time, you will then see the password reset tool.
Pre-Reset Confirmation Page
I decided to implement a page that appears before the actual reset tool to confirm users actually know their password. This isn't just a simple yes/no question – I built in a double confirmation system to make users really think about their response.
The page asks: "Please can you confirm you know your current correct password?"
I added a prominent warning notification that states: "If you answer YES, you will not be able to reset your password without knowing the current one."
The Reality of User Behavior
I'm fully aware that the majority of users will simply click "yes" when they should click "no."
Why?
Because clicking "no" gives them an error message saying they cannot use the service. Nobody wants to see an error message, so they'll naturally gravitate toward the option that seems to keep them moving forward.
However, this apparent flaw is actually intentional. For security reasons, you absolutely need to know your current password before you can reset it..
The Double Confirmation Challenge
Getting the double confirmation system working presented several interesting technical challenges that I had to overcome.
Challenge 1: User Experience vs Security
I needed to balance making the system secure without making it so cumbersome that legitimate users would abandon the process. The solution was a clean, professional dialog that appears when users click "yes" the first time, asking them to reconfirm their decision.
Challenge 2: JavaScript Redirect Issues
Initially, I tried using JavaScript's window.location.href to handle the redirect after the second confirmation. However, I discovered that browser security restrictions in certain environments prevent JavaScript redirects from working properly. The function would execute, but users wouldn't actually be redirected.
Fixing this involved converted the second confirmation button from a JavaScript-triggered button to a direct HTML link. This bypassed all the browser security restrictions and provided a more reliable user experience.
Challenge 3: Making It Feel Natural
I didn't want the double confirmation to feel like a punishment or an obstacle course. Instead, I designed it as a smooth, professional interaction with subtle animations and clean styling. The confirmation dialog slides in naturally, and users can easily back out if they realize they don't actually know their password.
Process Flow
The system works through a layered approach:
- Initial Question: Users see the main question with a clear warning about what "yes" means
- First Confirmation: Clicking "yes" triggers a professional dialog overlay
- Second Confirmation: The dialog asks them to reconfirm, with options to proceed or cancel
- Final Action: Only after two explicit confirmations do they reach the actual password reset tool
Conclusion
While I know some users will still click "yes" twice without really knowing their password, at least now they've been warned multiple times about the consequences. They can't claim they weren't told that the system requires them to know their current password.
For users who genuinely don't know their password, they'll quickly discover that the "yes" path doesn't work for them, and they'll need to use proper account recovery methods instead.