User Enumeration via Response Timing in heroiclabs/nakama


Reported on

Aug 23rd 2022


There is a significant timing difference in the login functionality of the Nakama Console for valid and invalid email addresses or usernames.

Proof of Concept

1. Login to the Nakama Console as admin and create a User
2. Logout
3. Attempt a Login with an incorrect password with and and observe the difference in the response time

Here is a small test script (alternatively we can see the response time in Burp Repeater)

import requests

url = ""
valid_user = {"username": "", "password": "pw"}
invalid_user = {"username": "", "password": "pw"}

for _ in range(3):
    r =, json=valid_user)


for _ in range(3):
    r =, json=invalid_user)

My test results:


We can see that there is a difference in response time of about 50 ms. This is because a computationally expensive hash function is only executed when the username is valid. Remember that a user is locked out after 5 consecutive failed login attempts, which means that the difference in response time cannot be observed anymore.


An attacker is able to identify valid email addresses and usernames. This could allow for further attacks such as brute force attacks on valid accounts.


The hash function is only executed when the username exists in the database. To mitigate this, the hash function should be executed with a dummy input even when the username does not exist.

We are processing your report and will contact the heroiclabs/nakama team within 24 hours. 7 months ago
vautia modified the report
7 months ago
We have contacted a member of the heroiclabs/nakama team and are waiting to hear back 7 months ago
heroiclabs/nakama maintainer has acknowledged this report 7 months ago
6 months ago


Is there any update @maintainer?

Andrei Mihu validated this vulnerability 2 months ago
vautia has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Andrei Mihu marked this as fixed in 3.16.0 with commit ada6f9 2 months ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
This vulnerability is scheduled to go public on Feb 1st 2023
Andrei Mihu published this vulnerability 2 months ago
to join this conversation