Reverse Online Guessing Attacks on PAKE Protocols

TL;DR

This paper addresses reverse online password guessing attacks on password-based key exchange (PAKE) protocols deployed without PKI by showing how an attacker can impersonate the server to validate guesses via the client. It formalizes the attack using Encrypted Key Exchange (EKE) as a concrete example and demonstrates its applicability to multiple PAKE variants, including SRP, OPAQUE, Dragonfly, and Owl. A symbolic-analysis methodology with ProVerif and CPSA reveals vulnerabilities and confirms that server authentication (e.g., PKI) mitigates the attack, while PKI-free deployments remain at risk. The work advocates explicit server authentication as a default precaution in PAKE standardization and deployment, and it discusses practical mitigations for scenarios like WPA3-SAE and phishing/pharming contexts.

Abstract

Though not yet widely deployed, password-authenticated key exchange (PAKE) protocols have been the subject of several recent standardization efforts, partly because of their resistance against various guessing attacks, but also because they do not require a public-key infrastructure (PKI), making them naturally resistant against PKI failures. The goal of this paper is to reevaluate the PAKE model by noting that the absence of a PKI -- or, more generally, of a mechanism aside from the password for authenticating the server -- makes such protocols vulnerable to reverse online guessing attacks, in which an adversary attempts to validate password guesses by impersonating a server. While their logic is similar to traditional guessing, where the attacker impersonates a client, reverse guessing poses a unique risk because the burden of detection is shifted to the clients, rendering existing defenses against traditional guessing moot. Our results demonstrate that reverse guessing is particularly effective when an adversary attacks clients indiscriminately, such as in phishing or password-spraying attacks, or for applications with automated login processes or a universal password, such as WPA3-SAE. Our analysis suggests that stakeholders should, by default, authenticate the server using more stringent measures than just the user's password, and that a password-only mode of operation should be a last resort against catastrophic security failures when other authentication mechanisms are not available.

Figures (6)

• Figure 1: The Encrypted Key Exchange eke protocol. A client and server, with knowledge of a shared password $P$, negotiate and verify a session key $R$.
• Figure 2: Overview of a reverse online guessing trial. The adversary impersonates a server to trick the client into becoming a password oracle.
• Figure 3: The initial exchange between a client and a server to establish a secret verifier based on the client's password at the verifier. It includes a final send in the server-init role that releases the verifier to the adversary to simulate a correct password guess.
• Figure 4: Run of TLS 1.2 using SRP where the password is not correctly guessed by an adversary. Client completes run with the server with injective agreement on all variables as indicated by the solid lines between the roles.
• Figure 5: Run of TLS 1.2 using SRP where the password is correctly guessed by an adversary as shown with the fifth message from the server-init role. Client completes run without the server indicating an attack. The client does not know with whom the protocol completes, but believes it completed with the server.