HashAdapter Interface
TheHashAdapter interface is extremely simple:
- Takes a string input, returns a string hash
- Should be deterministic (same input = same output)
- Synchronous operation
- Faster is better (called on every storage write)
How It Works
The achievement engine uses hash adapters for tamper detection:-
When saving data to storage, the engine:
- Serializes the data to a string
- Computes a hash of that string
- Stores both the data and hash (with
:hashsuffix)
-
When loading data from storage, the engine:
- Retrieves both the data and stored hash
- Recomputes the hash of the data
- Compares the two hashes
- If they don’t match, calls
onTamperDetectedand wipes the data
Default Hash Adapter
The package includes a default FNV-1a hash implementation:- Fast and synchronous
- Sufficient for detecting accidental corruption or casual tampering
- 32-bit hash (not cryptographically secure)
- Good default for most use cases
Custom Hash Examples
Crypto API Adapter (Async to Sync Bridge)
Use the Web Crypto API with a synchronous wrapper:MurmurHash3 Adapter
Faster than FNV-1a, still non-cryptographic:CRC32 Adapter
Simple checksum for detecting corruption:HMAC-Style Adapter with Secret
Add a secret key for stronger protection:xxHash Adapter
Extremely fast non-cryptographic hash:Choosing a Hash Algorithm
For Most Use Cases
Use the defaultfnv1aHashAdapter()
- Fast enough for achievement systems
- Detects accidental corruption
- Deters casual tampering
- No dependencies
For High-Performance Needs
UsexxHashAdapter() or murmur3HashAdapter()
- Faster than FNV-1a
- Better distribution
- Still non-cryptographic
For Strong Tamper Protection
Usesha256HashAdapter() with caching
- Cryptographically secure
- Very difficult to forge
- Slower, but cached results help
- Good for competitive/leaderboard systems
For Simple Corruption Detection
Usecrc32HashAdapter()
- Very fast
- Standard checksum
- Only detects accidental changes
Testing Your Hash Adapter
Performance Benchmarking
Security Considerations
Client-Side Limitations
All client-side tamper detection has fundamental limits:- Users have full control of their browser
- JavaScript can be modified or debugged
- Storage can be manually edited
- Hashes can be recomputed by modified code
Best Practices
-
Use hash adapters to detect casual tampering and accidental corruption
- Good: Detecting corrupted localStorage
- Good: Deterring console-based cheating
- Bad: Preventing determined attackers
-
For critical achievements, validate server-side
-
Use stronger hashes for competitive features
- Leaderboards
- Multiplayer achievements
- Rewards/prizes
-
Combine with other anti-cheat measures
- Rate limiting
- Behavioral analysis
- Server-side validation
Next Steps
- Vanilla JS Guide - Learn core achievement system usage
- React Integration Guide - Use with React
- Custom Storage Guide - Implement custom storage adapters
