Understanding Timing Vulnerabilities: A Real Bug Hunting Experience

Timing vulnerabilities are often overlooked because they do not immediately expose sensitive data or allow account takeover. However, differences in application response times can unintentionally reveal information that attackers can exploit. During bug bounty research, I encountered a timing-based user enumeration issue that demonstrates how seemingly harmless implementation details can leak useful information.

What is Timing Vulnerability?

A timing vulnerability is a type of side-channel security issue where an application takes different amounts of time to process different inputs. An attacker can measure these response-time differences to infer sensitive information that should not be disclosed.

Even very small timing variations can reveal whether a username exists, whether part of a password or token is correct, or, in some cases, information about cryptographic operations.

What causes this vulnerability?

• Conditional Logic & Early Exits : Code often uses standard if/else loops or string comparison functions (like checking a password) that terminate the moment a mismatch is found. This means a partially correct input takes longer to process than a completely incorrect one.
• Data-dependent Cryptographic Operations : Certain math operations used in cryptography (such as modular exponentiation) perform different calculations depending on whether a processed bit is a 0or 1, leading to measurable execution variations.
• Hardware-level Behaviours : Modern CPU features like branch prediction and memory caching naturally speed up processes that have been run recently or follow a predicted path, unintentionally introducing subtle timing differences based on the data processed.

How I found this vulnerability?

During independent security research, I was testing a web application that is part of the HackerOne bug bounty program.

The application required users to register using their HackerOne username before proceeding.

While interacting with the registration workflow, I observed that the server consistently responded at different speeds depending on whether the supplied HackerOne username existed.

• Existing HackerOne username: ~7 seconds
• Non-existent HackerOne username: ~4 seconds

To eliminate the possibility of network fluctuations, I repeated the test multiple times using the same environment. The timing difference remained consistent, indicating that the application was performing additional processing only for valid usernames.

This behavior allowed an attacker to distinguish valid usernames solely through response-time analysis.

Potential Impact

• User enumeration : Attackers can determine whether a particular username or account exists without authentication. This enables the creation of a list of valid accounts for further attacks.
• Credential stuffing & Password brute forcing : Once valid usernames are identified, attackers can focus password spraying, credential stuffing, or brute-force attempts only against existing accounts, making these attacks more efficient.
• Targeted Phishing and Social Engineering : Knowledge of valid usernames allows attackers to craft more convincing phishing emails or impersonation attempts against specific users.
• Privacy disclosure : In applications where usernames or email addresses are intended to remain private, timing differences may unintentionally expose the existence of user accounts.

Prevention

• Use constant-time comparison functions when comparing passwords, API keys, authentication tokens, signatures, and other sensitive values.
• Ensure identical processing paths for both valid and invalid inputs whenever possible.
• Return generic error messages that do not reveal whether a username or email exists.
• Normalize response times by avoiding unnecessary differences in backend processing for different outcomes.
• Apply rate limiting and account lockout mechanisms to reduce large-scale enumeration attempts.
• Continuously monitor logs for repeated username enumeration or abnormal authentication behavior.
• Perform regular security testing to identify observable timing differences before deployment.

Why I did not report it?

Although I observed a consistent timing difference, I chose not to report the finding because I could not demonstrate a meaningful security impact beyond potential user enumeration. Most bug bounty programs require a clear, exploitable impact for a report to be considered valid or eligible for a reward. This finding was a useful learning experience in understanding the importance of impact when assessing vulnerabilities.

Conclusion

Although response-time differences may appear insignificant, they can leak valuable information to attackers. In this case, the measurable delay between valid and invalid HackerOne usernames enabled reliable user enumeration through timing analysis. Eliminating observable timing differences and ensuring consistent request handling are essential to preventing this class of side-channel vulnerability.