Using Cryptographic Hashes To Secure High Score Submissions

Preventing Score Tampering with Hashes

A cryptographic hash function is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size. It is a one-way function, meaning that it is easy to compute the hash for a given input but extremely difficult to generate the original input from the hash value alone. Cryptographic hash functions have applications in data integrity checks as even small changes to the input data will produce major changes in the resulting hash value.

Hashes can be used to detect unauthorized changes or tampering with data. Game high score systems can leverage cryptographic hashes to verify that submitted scores have not been altered or falsified. When a player achieves a new high score, the game generates a hash value from the score and relevant metadata such as the player’s name and transmission timestamp. This hash is transmitted and stored along with the score data on the game server.

To validate a high score submission, the server recomputes the hash using the submitted player name, score counter, timestamps and other details. If the newly generated hash matches the one computed originally by the game client, then the server can safely conclude that the score has not been altered in transit and store it. Even minute changes to the score or metadata would cause a mismatch between the original hash and server-computed hash, allowing tampering to be detected.

Table of Contents

Hashing High Scores Before Transmission

Here is how hashing can be integrated into a game to secure scores before transmission to server:

Player enters name and achieves a new high score playing the game on client device.
The game takes the player’s name string, combines it with the score counter integer value, current timestamp and any other relevant metadata.
This combined data is fed into a cryptographic hash algorithm like SHA256 implemented on the client.
The resulting 256-bit hash value is concatenated together with the original name, score and metadata.
This hash + data package is transmitted securely over HTTPS/SSL to the game server for storage and ranking.

Implementing a Basic High Score Hash System

Implementing a basic hashing system for securing high score submission involves actions on both the game client and the server:

Generating Hash on Client

The game client first concatenates the player name string and score counter integer together. This concatenated data is then fed into a cryptographic hash algorithm, like SHA256, implemented in the game code. The 256-bit digest output from the hash function is the hash value which will be verified by the server.

Transmitting Hash and Score to Server

The hash string is concatenated together with the original player name and score counter variables. This data package is secured with transport layer encryption such as SSL/TLS before being transmitted over the internet to the game server.

Verifying Hash on Server

The game server receives the transmitted data package and extracts the player name, score counter and hash string into separate variables. It concatenates the name and score variables again in the same manner as performed on client. This concatenated data is fed into the same hash algorithm used by the game client (SHA256), and the output is the server-computed hash.

The server now compares the client-computed hash string with its own hash digest. If the two hash values exactly match, the server concludes that the score data has not been tampered with in transit. The score can now be safely stored and ranked on the leaderboard.

Improving Security with Salts and Iterations

While hashing high scores provides basic tamper detection, additional steps can be taken to improve the strength:

Salts

A salt is random data concatenated with the original input before hashing to ensure each player’s hash is unique. This protects against precomputed “rainbow table” attacks. The salt does not need to be secret but must be different for each score transmission.

Iterations

Running thousands of iterations of the hash algorithm greatly increases the computation time needed to brute force a hash-score pairing. This helps mitigate a brute force attack attempting to find input data that generates a target hash.

Example Implementation

Here is how salts and iterations can be implemented to strengthen high score hashes:

Client generates a 128-bit random salt value for each score submission.
The salt is concatenated with the player name and score.
This salted data is passed into 5000 iterations of the SHA256 algorithm.
The final 256-bit hash is sent to server along with the salt and score data.
Server extracts salt and regenerates the hash with 5000 SHA256 iterations based on the transmitted score and salt.
Server compares hashes to verify integrity as before.

Detecting Cheaters While Preserving Privacy

To prevent a single player from submitting multiple high scores under different names, names must be sent to the server. However directly transmitting names raises privacy concerns. These issues can be addressed by:

Omitting Transmission of Direct Names

Instead of sending actual player names, the client can transmit a salted hash digest of the name. This preserves anonymity while still allowing the server to detect duplicate hash values tied to the same player.

Use of Player-Specific Salts

The client can concatenate a device-specific identifier, like a GPU serial number, to each player name before hashing. This ties every score submission from that client to the same player while keeping the name itself private.

Preserving Cheater Detection

Since anonymous salted name hashes are still unique per player, duplicating the exact hash digest for multiple score submissions would be computationally infeasible. The system still prevents a single player from cheating the leaderboard with multiple identities.

Next Steps for More Robust Score Systems

Additional client and server-side measures can enhance high score security:

Added Client Verification

Before allowing score submission, the client can implement supplemental checks like analyzing for application modification, running in emulators and validating score achievement timing.

Server-Side High Score Sanity Checks

On the server, statistical analysis of scores over time can detect sudden unrealistic spikes suggestive of tampering. For example, scores improving several standard deviations beyond a player’s historical performance may indicate cheating.

Score Delay and Review

New high score submissions can be delayed from publishing instantly on the public leaderboard. Potentially suspicious scores can be flagged for manual review before publishing or rejection.