$ security
How AuthForge protects your licensing.
Licensing is an attractive target. A valid response is worth real money to a determined attacker, and a vulnerable validator can be cracked once and copied forever. AuthForge is built so that even a compromised network or a replayed payload cannot trick your application into accepting a forged license. This page walks through the cryptography, the runtime checks, the operational rate limiting, and what we explicitly do not store.
Ed25519-signed validation responses
Every successful validation and heartbeat response is signed by AuthForge with an Ed25519 private key that lives only inside our infrastructure. Your application ships with the public key (visible in your dashboard under App settings → Security) and verifies the signature locally before honoring the response. If the signature does not verify, your app treats the response as if the network had returned 403.
This matters because the practical attack surface for licensing isn't breaking AES-256 over TLS; it's the user. The user (legitimate or otherwise) sits between your app and our servers, and can run a local proxy, a debugger, or a patched DNS. Without signed responses, all an attacker has to do is intercept any single positive response, edit a few bytes, and replay it. With signed responses, the only way to forge a license is to extract our private signing key, which never leaves our hardware-backed signing path.
Nonce-based replay protection
A signed response is still vulnerable to a replay attack if the same payload can be replayed verbatim. To stop this, your SDK generates a per-request 128-bit nonce and includes it in the request body. The nonce is incorporated into the signed response. The SDK then checks that the response nonce matches the request nonce before accepting it. If a network attacker captures a valid response and replays it on a fresh request, the nonce mismatch causes the SDK to reject the response.
Combined with the signature check, this means an attacker has to either extract our private key (not feasible) or break Ed25519 in real time between request and verification (also not feasible). The licensing flow is end-to-end authenticated, not just transport-encrypted.
HWID and IP allow/deny lists
Each application supports per-app allow and deny lists for both HWIDs and source IPs. Use the deny list to neutralize a leaked key the moment you spot it, and the allow list to lock production traffic to a known set of machines (handy for internal tools, kiosk deployments, or licensed servers). Lists update in real time; the next validation request from a banned HWID is rejected without consuming credits.
Hardware locking itself is configured per license: each license carries a maximum HWID seat count, and validation requests bind a fresh HWID into the next free slot until that count is reached. Resets can be issued manually from the dashboard, automated through the developer API, or self-served through your hosted customer portal under a policy you set.
Rate limits and per-app burn caps
Every public endpoint (validate, heartbeat, self-ban, customer portal lookups) sits behind layered rate limits at the AuthForge edge. The first layer is request-rate per HWID, then per source IP, then per license, then per application. A license that suddenly attempts thousands of validations per second is throttled before the traffic ever touches our handler.
Per-app burn caps are the second line of defense. You set a maximum credit burn rate for each application, and AuthForge automatically temporarily disables further validations on that app once the cap is hit. This prevents a runaway integration bug or a malicious flood from draining your account balance overnight.
Self-ban flow
If your application detects an abuse condition mid-session (for example, a memory editor attached, a debugger detected, or a script attempting privileged actions), it can call the self-ban endpoint to immediately revoke the active license. The endpoint accepts an HWID, marks the license as banned, optionally invalidates any active sessions, and returns to your app within a single request round-trip.
This lets you ship an automatic anti-abuse response without needing your backend or our dashboard in the loop. The user gets locked out, you stop paying for their heartbeats, and your support team gets a webhook event they can investigate later.
Transport security
All AuthForge endpoints are HTTPS-only. We serve Strict-Transport-Security
with a long max-age and includeSubDomains, so once a browser
(or your SDK's HTTPS client) talks to authforge.cc once, it
will refuse to downgrade to plain HTTP for the duration of the policy.
TLS termination is handled by managed AWS infrastructure with modern
cipher suites only; older protocols are disabled.
The signed-response model means even if TLS were somehow bypassed, an attacker still couldn't forge a positive validation. Transport security is the first layer; cryptographic signing is the second; and rate limiting is the third. They compose, rather than depending on each other.
What AuthForge does not store
AuthForge stores enough to operate your licensing: license keys, metadata, HWID bindings, validation/heartbeat counters, webhook delivery history, and the operator account identifiers managed by AWS Cognito (email, sub, group membership). We do not store end-user PII beyond the identifiers your application sends us; we don't know your customer's name, address, or credit card. If you bind an HWID, that's what we get; if you forward an end-user email through the customer portal, we use it to send the receipt and stop there.
For credit purchases, payment data is processed by Stripe; we receive only the metadata Stripe returns to a webhook (event id, amount, success status). Card numbers, CVCs, and full billing addresses never touch our infrastructure. See the privacy policy for the legal version.
Found something concerning?
Email security@authforge.cc with reproduction steps. We respond to confirmed reports within one business day and credit reporters in our changelog when they're comfortable with public disclosure.