Skip to main content

Game Security

Game Securityđź”’

Introduction

Before we dive into required functions, let’s go over the security requirements for listing on Haste. This should not be an afterthought, so we encourage you to start thinking about your game security before you begin developing.

Since the games on the Haste arcade provide financial payments through the instant leaderboard payouts (HLP) service, there is a stronger incentive for players to cheat. In order to protect non-malicious users and the reputation of the Haste Arcade, the Haste Arcade does require any published games to adhere to certain security standards. As we move forward, the Haste team will continuously update this documentation with further details and provide examples. If you have any questions, please reach out to us on Discord.

It is likely impossible to completely defeat any potential malicious user, but we strive to make it as difficult as possible. As Haste Arcade grows, we will be making Security a top priority and providing tools to developers to ensure their games can be trusted.

Table of Contents​

The Authoritarian Game Security Model​

All games listed in the Haste Arcade should follow the Authoritative game server model. Essentially, this means that the client sends instructions/information to the server, and the server then validates this and updates proxies and the client accordingly.

For example, if a player tries to move 1000 m/s but the server knows the max client velocity is 10 m/s, the player will be forced back into the correct position by the server.

This model is suited for competitive games like those following our HLP model; the authoritative server makes it much harder for clients to hack the game and cheat to win. For more info on the Authoritarian Game Security Model, check here.

Example Architecture for Server Authority​

Haste Server Authority Example

Best Practices for Client Secrets​

All games must store client secrets in a secure location. Storing and managing secrets can be challenging, so here's a quick cheat sheet of best practices to keep credentials secure.

  1. Never store unencrypted secrets in .git repositories. If you ever accidentally commit a secret to the repository, you should go back to theDeveloper Portal to reset your secrets under your game's details.
  2. Store secrets safely. Here are a couple of ways you can do that:
    • Use git-secrets to encrypt your secrets within your .git repository.
    • Use local environment variables when you can.
    • Use a 'secrets as a service' solution like Hashicorp Vault.
  3. Restrict permissions to your games as much as possible.
  4. Don't share secrets via messaging services like Slack, Teams, Skype, etc. Try to use encrypted messaging services like Keybase or Signal instead.
  5. Make sure you're using different secrets for different environments and do not share secrets between environments.

This is a great resource if you're looking for more information on managing secrets.

Security Requirements​

Before deploying your game, we recommend taking a look at this list of high-level security requirements. To list your game in Haste Arcade, you must comply with these requirements.
  1. Follow the Authoritarian Game Security Model. At its core, scoring should occur server-side. Anything on the client should be considered open to the public and easy to manipulate.
  2. All game developers should consider how a well-developed bot could cheat their game. Artificial Intelligence and Machine Learning are fairly sophisticated these days and can even play Starcraft well. While it is unlikely certain AI or ML models could learn quickly enough to beat "fast" games like the original Haste games, never forget that people are innovative and could beat your game with a simple bot if you are overlooking security. For example: consider it likely someone would write a script to read the display buffer and look for certain groupings of pixels. Someone could also parse the HTML markup and perform moves based on how the markup is laid out. Think the vulnerabilities in your game through and anticipate potential cheating.
  3. All games use the authentication and authorization SDKs or APIs provided by Haste Arcade.
  4. All games must store secrets in a secure location. Examples of secure locations and more details on storing secrets can be found here in our documentation. Examples of non secure locations would include, but are not limited to: Store secrets safely. Here are a couple of ways you can do that:
    • Secrets are stored as a static variable within a client-side application such as a React SPA. See this for more details related to a create-react-app example. In particular, you should note their WARNING at the top with regards to private keys.Use git-secrets to encrypt your secrets within your .git repository.
    • Committed to a Github repository.Use local environment variables when you can.
    • Written on a sticky note by your computer.Use a 'secrets as a service' solution like Hashicorp Vault.

“The client could run the simulation code for their own character and simply tell the server where they are each time they send a packet. The problem with this is that if each player were able to simply tell the server “here is my current position” it would be trivially easy to hack the client such that a cheater could instantly dodge the RPG about to hit them, or teleport instantly behind you to shoot you in the back.”

- Glenn Fiedler

Source

© 2023 Haste, Inc.