CompChall: Addressing Password Guessing Attacks

Even though passwords are the most convenient means of authentication, they bring along themselves the threat of dictionary attacks. Dictionary attacks may be of two kinds: online and offline. While offline dictionary attacks are possible only if the adversary is able to collect data for a successful protocol execution by eavesdropping on the communication channel and can be successfully countered using public key cryptography, online dictionary attacks can be performed by anyone and there is no satisfactory solution to counter them. This paper presents a new authentication protocol which is called CompChall (computational challenge). The proposed protocol uses only one way hash functions as the building blocks and attempts to eliminate online dictionary attacks by implementing a challenge-response system. This challenge-response system is designed in a fashion that it does not pose any difficulty to a genuine user but is time consuming and computationally intensive for an adversary trying to launch a large number of login requests per unit time as in the case of an online dictionary attack. The protocol is stateless and thus less vulnerable to DoS (Denial of Service) attacks.

💡 Research Summary

The paper “CompChall: Addressing Password Guessing Attacks” tackles the persistent problem of online dictionary attacks, which remain largely unsolved despite numerous counter‑measures for offline attacks. The authors first review existing defenses—account locking, delayed responses, and CAPTCHAs—highlighting their drawbacks: account locking is vulnerable to denial‑of‑service (DoS) because an attacker can deliberately trigger lockouts; delayed responses can be bypassed by parallel requests; and modern AI can solve CAPTCHAs, rendering them ineffective.

To overcome these issues, the authors propose CompChall, a stateless authentication protocol that relies solely on fast one‑way hash functions and a secret server key for MAC generation. The protocol consists of four messages:

1. Client → Server: a simple login request.
2. Server → Client: the server generates a 20‑bit random value r and a 128‑bit random salt R. It sends H(r‖R), the salt R, and a MAC computed as H(H(r‖P)‖Alice‖K_Bob‖n), where P is the user’s password, K_Bob is a server‑only secret, and n is the count of previous failed attempts.
3. Client → Server: after receiving the challenge, the client must recover r by brute‑forcing all 2²⁰ possible values, testing each against the received H(r‖R) together with the known R. Once the correct r is found, the client sends its identifier, H(r‖P), and the unchanged MAC back to the server.
4. Server → Client: the server recomputes the MAC using the received H(r‖P), its secret key, and the current n. If the MAC matches, authentication succeeds; otherwise it fails and increments n.

Key security properties stem from this design:

• Computational throttling: The mandatory 20‑bit brute‑force step forces every login attempt to consume a measurable amount of CPU time (≈5 seconds on a typical desktop). An attacker cannot launch thousands of attempts per second without incurring prohibitive cost.
• Salted challenge: The 128‑bit random R acts as a per‑session salt, preventing pre‑computation of the 2²⁰ hash table. Each login requires a fresh exhaustive search, nullifying offline rainbow‑table attacks on the challenge.
• Statelessness: The server never stores r, R, or session state. Authentication is verified solely via the MAC, which incorporates the failure counter n. Consequently, the server’s workload is limited to a few hash and MAC operations, making the system resilient to DoS floods.
• Replay protection: Because n is included in the MAC, a replay of a previously captured message 3 will fail after any intervening unsuccessful attempt (n will have changed). Successful logins do not increment n, allowing legitimate users to reuse the previously computed r on subsequent logins, reducing user‑side latency.

The authors acknowledge that the protocol does not protect against offline dictionary attacks if an adversary records a full exchange. They recommend wrapping the protocol in an SSL/TLS channel, which is already standard practice for web logins, thereby encrypting the exchanged hashes and MACs.

Performance considerations are discussed: the server’s cost is minimal (hash + MAC), while the client bears the bulk of the work. The size of r can be adjusted to match evolving hardware capabilities, offering a tunable security‑performance trade‑off.

Limitations include: (1) the computational burden may be noticeable on low‑power devices (e.g., older mobiles, IoT nodes); (2) the protocol’s security against offline attacks depends on external transport encryption; (3) the secrecy of K_Bob is critical—its compromise would break the MAC integrity.

In conclusion, CompChall presents a pragmatic, low‑overhead method to curb online password‑guessing attacks by imposing a controlled, per‑login computational puzzle and eliminating server‑side state. Its design addresses the primary flaws of earlier defenses while remaining compatible with existing infrastructure, provided that SSL/TLS is used and proper key management is enforced.