Security model
What this design actually protects, and what it cannot. Both halves matter.
What is protected
- Keys are not stored in a usable form. Each is an HMAC for lookup plus a separate ciphertext. No column holds a key you could read out of a database dump, and a test asserts that.
-
Application secrets and variable values are encrypted with
APP_KEY, so a database leak alone does not hand over your secrets. - Nothing usable crosses the wire. Keys are derived per message with HKDF and never transmitted. Capturing traffic yields no reusable material.
- Responses cannot be replayed or repurposed. Direction separation stops a request being replayed as a response, and response keys mix in the request signature so a captured response is useless against any other request.
- Files are chunk authenticated. Each chunk carries its own AES-256-GCM tag bound to its index, so chunks cannot be reordered, swapped between files or replayed.
-
Enforcement is server side. Bans, device limits, concurrency caps, rate limits and
blacklists are all decided here, and
validatere-checks them mid session. - Dashboard actions are audited. Key reveals, secret rotations, exports and SDK downloads are all recorded.
What cannot be protected
The secret in your binary is recoverable
Your client signs requests, so it must hold the application secret. The generated SDK masks it with a
fresh XOR pad on every download, which defeats strings, but a determined reverse
engineer will find it. No client side scheme can avoid this; anyone claiming otherwise is selling
obfuscation as security.
The mitigation is operational, not cryptographic: rotate the secret when you suspect a leak and ship a rebuilt loader. Meanwhile the payload itself still never leaves the server without a valid key.
A tampered client can lie about anything it sends
Version strings, hardware ids and log messages all come from a process the attacker controls. This is why version checks and bans are decided by the server, and why client initiated bans are off by default: a patched binary could otherwise ban a key it does not own.
A CPU only hardware id is not per machine
CPUID reports a model, not a chip. Customers with the same processor share a hardware id, so device limits cannot separate them. See hardware locking.
Your responsibilities
| Item | Why |
|---|---|
| Serve over HTTPS | Session cookies are marked secure, and certificate pinning needs TLS. The protocol survives a hostile network, but your dashboard login does not. |
Document root at public | Otherwise .env, and your APP_KEY, is downloadable. |
APP_DEBUG=false | Debug pages expose configuration and stack traces. |
Back up APP_KEY | Losing it means losing every encrypted secret and variable. |
Set TRUSTED_PROXIES correctly | Wrong either way, IP blacklists and rate limits stop working or become spoofable. |
| Keep registration closed | Anyone registering gets their own tenant on your server. |
| Leave client bans off | Unless you genuinely need them. |
A note on the threat model
This design does not try to make your binary un-crackable, because that is not achievable. It tries to make cracking pointless by keeping the valuable part on the server. An attacker who fully reverses your loader still needs a live, unbanned key to obtain the payload, and every request they make is logged against that key.