How the Login Detection Method Works in holehe: Email Verification Through Authentication Endpoints

The login detection method in holehe verifies whether an email address is registered on a service by submitting authentication requests to login APIs and interpreting HTTP responses—including redirects, error payloads, and JSON flags—to determine account existence without valid credentials.

holehe by megadose is an open-source intelligence (OSINT) tool designed to identify where an email address has been used across hundreds of online platforms. The login detection method serves as one of the primary mechanisms enabling this reconnaissance, allowing individual modules to systematically probe authentication endpoints and infer account status from response patterns rather than successful logins.

Understanding holehe's Login Detection Architecture

Module Declaration and the method Constant

Every module implementing this technique declares method = "login" near the top of the file. This constant signals to holehe's core orchestrator that the module follows the login detection contract. Files such as holehe/modules/social_media/snapchat.py and holehe/modules/social_media/patreon.py use this declaration to indicate they perform authentication-based email verification, enabling the framework to treat dozens of services uniformly.

Core Orchestration via launch_module

The central dispatcher resides in holehe/core.py, specifically within the launch_module function (lines 66-71). This async function invokes each module's detection routine, standardizing the execution flow across disparate services. The core handles exception normalization, ensuring that unexpected failures are captured and reported uniformly alongside successful checks, effectively isolating service-specific logic from the broader execution pipeline.

Execution Flow of the Login Detection Method

Requesting Authentication Endpoints

When executed, a module sends an HTTP request—typically POST—to the target service's login API, supplying the target email as a parameter. For example, in holehe/modules/social_media/snapchat.py (line 14), the module posts to https://accounts.snapchat.com/accounts/merlin/login with a payload containing the email and a dummy password to trigger the authentication response without valid credentials.

# Example from holehe/modules/social_media/snapchat.py

method = "login"
url = "https://accounts.snapchat.com/accounts/merlin/login"

async def snapchat(email: str, client, out):
    data = {"email": email, "password": "dummy"}          # dummy password

    response = await client.post(url, data=data)
    # If the JSON contains "error", the email is not registered

    exists = not response.json().get("error")
    out.append({"name": "snapchat", "domain": "snapchat.com",
                "exists": exists, "rateLimit": False,
                "error": False, "emailrecovery": None,
                "phoneNumber": None, "others": None})

Analyzing Response Patterns

The module examines the HTTP response to deduce account status through three primary indicators:

• Redirect indicators: A redirect to a login page suggests the email requires authentication, often implying the account does not exist or requires additional verification steps.
• JSON flags: Services like Komoot return payloads containing "type": "login" (visible in holehe/modules/medias/komoot.py, line 25), which the module interprets as confirmation that the email is not associated with an existing account.
• Success markers: Absence of error fields, specific success codes, or alternative response structures confirm the email has been used to register on the platform, triggering an exists: True result.

Handling Rate Limits and Errors

HTTP 429 responses and other error codes are captured explicitly within the module logic. Rather than marking the account as existing or non-existing, the module sets rateLimit: True or error: True flags in the standardized result dictionary. This distinction allows holehe users to differentiate between technical failures and definitive negative results.

Code Implementation Examples

The following pattern from holehe/core.py demonstrates how the framework handles modules implementing the login detection contract, including exception normalization:

# Generic handling in the core launcher (holehe/core.py)

async def launch_module(module, email, client, out):
    try:
        await module(email, client, out)          # module follows the "login" contract

    except Exception:
        # Normalise unexpected failures

        out.append({"name": name, "domain": data[name],
                    "rateLimit": False, "error": True,
                    "exists": False, "emailrecovery": None,
                    "phoneNumber": None, "others": None})

Summary

• Modules declare method = "login" to opt into the authentication-based detection protocol, signaling the core launcher to treat them as login-style checks.
• The core launch_module function in holehe/core.py (lines 66-71) standardizes execution and exception handling across all login-method modules.
• Detection relies on analyzing HTTP responses—including redirects, JSON error fields like "type": "login", and status codes—rather than successful authentication.
• Rate limiting (HTTP 429) and connection errors are explicitly tracked separately from existence boolean values, preserving data integrity.
• This uniform request-response inspection pattern enables holehe to scale across hundreds of services with minimal per-site customization.

Frequently Asked Questions

What is the login detection method in holehe?

The login detection method is a systematic approach implemented by individual modules where the tool sends authentication requests containing the target email to service login endpoints. By analyzing the resulting HTTP responses for specific indicators—such as error messages, redirects, or JSON flags—the module determines whether the email is registered on that platform without requiring valid credentials.

How does holehe handle rate limiting during login checks?

When a module encounters HTTP 429 responses or similar rate-limit indicators during a login request, it captures these conditions as rateLimit: True in the result dictionary. This allows holehe to distinguish between technical restrictions preventing the check and the actual existence or non-existence of an account, ensuring users receive accurate state information.

Can the login detection method distinguish between invalid passwords and non-existent accounts?

Yes, the method specifically targets response patterns that indicate account status rather than authentication success. For instance, if a service returns a JSON field like "type": "login" or redirects to a login confirmation page—as seen in holehe/modules/medias/komoot.py—the module interprets this as the email not being registered, which is distinct from an "invalid password" response that would indicate account existence.

Where is the login detection logic centralized in holehe?

While individual service logic resides in module files under holehe/modules/, the orchestration is centralized in holehe/core.py within the launch_module function. This core component handles module invocation, manages the async client session, normalizes exceptions, and aggregates results into a standardized format for display or CSV export.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}