The Aiven login endpoint returns distinct error messages and 10-35x response time differences for registered versus unregistered email addresses, enabling reliable unauthenticated account enumeration.
The POST /v1/userauth login endpoint on api.aiven.io returns different error messages and significantly different response times depending on whether the submitted email address belongs to a registered Aiven account. A non-existent email receives the message "User does not exist" in roughly 150 ms. An existing email receives "user_password_compromised" in roughly 2,500 to 5,200 ms. The dual oracle (distinct message plus a 10-35x timing gap) makes enumeration highly reliable at scale. The password reset endpoint (/v1/user/password_reset_request) is correctly implemented and returns a uniform response regardless of email existence.
An attacker can determine which email addresses are registered on Aiven's platform without any authentication. This enables: - Targeted credential stuffing against confirmed accounts rather than random email lists - Targeted phishing campaigns that impersonate Aiven (for example, fake password reset emails directed only at confirmed users) - Confirming whether a specific employee or executive of a target organization uses Aiven
The timing difference alone is sufficient for reliable enumeration even if the error messages were normalized, because the 10-35x gap is consistent and well above network jitter.
The API checks whether the email address exists before validating the password. When the email is not found, it returns immediately with a not-found error. When the email is found, additional processing occurs, likely including a lookup against a password breach database (Have I Been Pwned or equivalent), before returning the authentication error. This secondary lookup accounts for the significant timing difference. Correcting this requires returning a generic "Invalid credentials" message for all authentication failures and normalizing response timing by always performing the same set of operations regardless of whether the email exists.
The two requests below illustrate both oracles. All test email addresses are generic placeholders.
Reported to Aiven through their bug bounty program. The recommended fix is to return a generic "Invalid credentials" message for all authentication failures (both non-existent email and wrong password) and to normalize response timing by executing the same operations regardless of whether the email is found. The password reset endpoint already implements this pattern correctly and can serve as a reference. Constant-time response can be approximated by always performing the breach database lookup (or a mock equivalent) before returning.