Cross-platform sessions allow one player to join the same match with multiple accounts

[ahmetcemkaraca]

Describe the bug

The same person can join one public match with multiple accounts by using openfront.io and the CrazyGames version at the same time.

I can join the same game with one account on openfront.io and a second account on CrazyGames without either account being blocked or penalized. I can also join with a third account by running another CrazyGames session.

This gives one player control of two or three starting positions and multiple sets of starting resources. Depending on the game mode, the extra accounts can transfer resources, protect the main account, or be deliberately absorbed to create an early advantage.

To Reproduce

1. Open openfront.io and sign in with account A.
2. Open OpenFront on CrazyGames and sign in with account B.
3. Join the same public lobby from both sessions.
4. Both accounts are admitted and can select separate spawn locations.
5. Optionally, open another CrazyGames session with account C and join the same lobby again.
6. Start the match and use the extra account or accounts to support the main account.

Expected behavior

A single person should not be able to control several active players in the same public match just by mixing openfront.io and CrazyGames sessions.

I do not know enough about the full production architecture to suggest one specific implementation. The solution should work across the supported sites, avoid punishing legitimate players on shared networks, and stay lightweight enough for the current game servers and peak lobby traffic.

I plan to work on this issue. I have reproduced the bypass in live games over the last two or three days, so the behavior is not based on a one-off test or an assumption.

Screenshots

I can add a recording showing both domains and all joined accounts if needed.

Desktop (please complete the following information):

• OS: Windows
• Browser: Chrome
• Version: Current stable version

Smartphone (please complete the following information):

• Device: Not tested
• OS: Not tested
• Browser: Not tested
• Version: Not tested

Additional context

Related issues: #571 and #589.

There are already protections for same-origin tabs and duplicate sessions on the same account, but the cross-platform case with separate accounts is still possible.

I would like this issue to stay open to ideas from maintainers and contributors who know the server architecture better. Some questions worth discussing are:

• Can this be handled mainly when players join a lobby, rather than adding continuous work during every game tick?
• Which account, session, network, or match signals are reliable enough to use without depending on browser fingerprinting alone?
• How can shared homes, schools, internet cafes, mobile carriers, and VPN users avoid false positives?
• Would a hard block, a lower per-match limit, risk scoring, or moderation flags fit the current infrastructure best?
• What limits should be placed on extra database calls, memory per lobby, network messages, and join latency?

I am happy to work on the implementation once the maintainers agree on an approach that the production servers can support.

Assignment

• I'd like to be assigned to this issue and work on it myself

[github-actions]

Hi @ahmetcemkaraca, thanks for opening this issue. It hasn't been approved by a maintainer yet — we'll get back to you shortly to either milestone it (approval) or close it.

— Automated. See CONTRIBUTING.md.

[ahmetcemkaraca]

I spent some more time looking through the current join flow and telemetry code. I think a background detection and manual review approach may be safer than hard-blocking every additional player from the same IP. Shared households, schools, workplaces and CGNAT could otherwise create too many false positives.

One possible direction would be to use the network information only on the server to identify candidate account pairs or groups. The telemetry or moderation API would not need to expose the raw IP. It could record a relation such as “same network observed” between distinct public accounts in the same public match.

The actual analysis could run asynchronously after the match instead of adding continuous work to the game loop. A case could combine signals from multiple matches, for example:

• The same account pair or group being observed on the same network across multiple public matches.
• The same accounts repeatedly appearing in matches together.
• Their actual resolved spawn positions being unusually close, normalized for the map size and player count.
• Differences in meaningful play time and inactivity, such as one account staying idle while the other is active.
• Alternating bursts of activity that may suggest one person switching between accounts.
• One-way gold or troop transfers where the game mode allows them.
• One account repeatedly sacrificing itself, feeding territory or being absorbed by the other.
• Disconnect and reconnect patterns that support the other evidence.
• Platform or authentication provider information as context only, not as proof by itself.

I would intentionally leave lobby join timing out of the score. I would also leave out whether the accounts avoided attacking each other or selected the same targets. Both seem noisy and could easily describe legitimate players.

There is also a limitation in the current spawn telemetry. The recorded spawn intent represents a requested tile, not necessarily the final spawn selected by the simulation. A player may submit more than one request, and random spawn rules can change the result.

To make spawn proximity useful, we may need a one-time, consensus-validated event after the spawn phase, something like resolved_spawn_snapshot, containing the actual final spawn positions. If the match uses random spawning, proximity should have little or no weight.

I do not think a risk score should automatically ban anyone. It should create an explainable suspicious or very suspicious case for manual review. The reviewer should be able to see the contributing signals, related matches and replays, activity and inactivity timelines, resolved spawn distances, transfers, eliminations and how often the same-network relation appeared.

This seems related to the approved moderation tracking issue #4064. If multi-account review and enforcement are not already covered there, I think they could be added as a sub-issue rather than creating a separate moderation system.

That moderation work could also track temporary and permanent account bans, including the reason, supporting evidence, moderator, start and expiry times, related accounts, action history and appeal or review status. Raw IP addresses should never be returned to the moderator UI, and enforcement should be account-based rather than using IP bans.

The implementation could probably be split into three parts:

1. Lightweight game-server telemetry for candidate relations and the resolved spawn event.
2. Post-match ingestion and pair/group risk analysis.
3. Integration with the moderation case and ban tracking work under [Feature] Moderation improvements — master tracking issue #4064.

I do not know the complete production ingestion and moderation architecture, so these are suggestions rather than a fixed implementation plan. Does this direction fit the existing telemetry and moderation roadmap? I would be interested in working on it once the approach is agreed on and the issue is approved.

[github-actions]

Hi @ahmetcemkaraca, this issue hasn't had activity in 7 days and doesn't yet have a milestone assigned.

If a maintainer doesn't milestone this issue (or you don't update it) within the next 7 days, it will be automatically closed.

If you believe this issue is important, consider:

• Adding more context, repro steps, or examples
• Discussing in our Discord
• Requesting the keep-open label if it should be exempt from auto-close

— Automated. See CONTRIBUTING.md.