Introduction

In a world where authentication is your first line of defense, you'd expect basic rules like "one email = one account" to be a no-brainer.

But during a routine test on a newly launched platform, I came across something odd: I was able to register twice with the exact same email address, each time using a different password — and the system allowed it.

It felt like opening two doors with the same key, but each led to a different room. Confused? So was the server.

Let me walk you through this misconfiguration, why it matters, and how to test for similar flaws in other applications.

The Setup: How I Found It

I signed up with:

After verifying my email and logging in, I decided to test something:

"What if I try to register again with the same email but a different password?"

To my surprise, the registration succeeded again — no errors, no warnings. And when I tried logging in…

What?!

The Vulnerability

This was a clear case of Broken Authentication caused by the lack of email uniqueness enforcement.

More technically, it could be due to:

  • Improper normalization of email (e.g., case sensitivity, not trimming whitespace)
  • Database misconfigurations allowing duplicate entries
  • Business logic flaws that don't treat email as a unique identifier

Instead of preventing or updating the existing account, the system was treating every registration as a fresh new account, even when the email already existed.

What I Tested

To explore the impact, I tested the following flows:

Login Behavior

  • Both accounts were accessible — but led to different user dashboards.

Password Reset

  • A password reset on [email protected] reset only one of the accounts.
  • The other remained accessible with its original password.

Data Separation

  • Each account had separate data (cart items, profile settings, etc.)
  • No shared tokens or sessions

Real-World Risks

Here's why this matters:

1. Account Takeover via Social Engineering

If a victim signs up and later forgets, an attacker could "sign up again" with the same email, creating a second account and causing confusion.

2. Bypassing User Limits

Some apps prevent duplicate registrations or invite limits by email — this bypasses that logic.

3. Breaking Login & Recovery Flows

Password resets may affect only one account — leaving others alive. This breaks the expected security model.

4. Fraud and Enumeration

Attackers could script account creation using variations of the same email (with aliases like +1) and abuse free trials, invite credits, etc.

How to Test It on Other Platforms

Want to check if your target is vulnerable?

Here's a simple methodology:

  1. Register an account with email [email protected] and a password.
  2. Register again with the exact same email and a new password.
  3. Login with both passwords.
  4. Try password reset, check if it targets a specific account or breaks completely.
  5. Look at user data — is it isolated or shared?

Bonus checks:

Suggested Fixes (for Developers)

  • Enforce case-insensitive uniqueness on email at the database level.
  • Normalize emails (e.g., lowercase, trim whitespace) before storing.
  • Prevent registration if an email already exists.
  • Update login and password-reset logic to handle only one unique account per email.

Conclusion

This bug may look simple — after all, what's the harm in signing up again? But in security, ambiguity is dangerous.

When a user's email isn't tied to a single identity, all kinds of trust assumptions break. If you're a developer, test your systems. If you're a hacker, don't ignore the simple stuff. Sometimes, it's not an RCE that gets you paid — it's just an overlooked login form.

Thanks