Skip to content

Conversation

@ftkg
Copy link
Contributor

@ftkg ftkg commented Jul 1, 2022

  • Adds a cache of failed login attempts, providing both account-based and IP-based lockouts after a number of failed login attempts have been received in a determined amount of time.

  • The user is locked from making any further login attempts until it automatically unlocks after a period of time.

  • A successful login clears the failed attempts for that account, but cached IP failed attempts only clear after the specific timespan.

@zyro zyro force-pushed the ft-console-brute-force-protection branch from b045f39 to 0962517 Compare July 5, 2022 18:21
@zyro zyro merged commit e2e02fc into master Jul 5, 2022
@ftkg ftkg deleted the ft-console-brute-force-protection branch July 6, 2022 13:27
uname = in.Username
id = uuid.Nil
} else {
if lockout, until := s.loginAttemptCache.Add(s.config.GetConsole().Username, ip); lockout != LockoutTypeNone {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zyro , @ftkg ,

there is a bug in extractClientAddressFromContext allowing IP address to be spoofed, making it easy to bypass this limiter. Bug is that IP address extracted as a first element of x-forwarded-for header, not rightmost (N - 1), where N is number of known proxies, as a result IP address as nakama knows it is entirely controlled by user.

Even without IP spoofing, with enough IP addresses available it looks like it is quite possible to exhaust server memory by authenticating with sufficiently log usernames. If we truncate username to something like 20 chars before storing in the cache it will be much harder to pull it off

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per this the left-most address is supposed to indicate the client address, assuming trustworthy proxies across the chain. Either way we'll leave IP-based restrictions for a later stage.

Account lockouts are only tracked for valid accounts that actually exist, a bad actor cannot fill up the list with arbitrary usernames.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assuming trustworthy proxies across the chain.

But we dont have trustworthy chain. User can make request with populated X-Forwarded-For and it will be the IP address nakama uses, because each intermediate hop appends to the list, so selecting ips[0] picks one provided by the user.

Account lockouts are only tracked for valid accounts that actually exist, a bad actor cannot fill up the list with arbitrary usernames.

I see, I misread the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants