Select programming language for code examples

linkSecurity

Below you will find various security tips you may find useful.

linkSecret API Tokens

If one of your admin API tokens become compromised, you can quickly revoke it from your admin dashboard.

In Client-facing Software

Do not embed your admin or product API tokens within client- or end-user-facing code. If you're using Keygen client-side, do not embed your admin or product tokens within your product's source code. Doing so exposes your tokens and opens your account up to attackers, regardless of how obfuscated the token is.

Instead, you can perform license and machine creation requests client-side while authenticated as one of your users, or by using an activation token which belongs to the license you're activating a machine for.

If you're using Keygen server-side, keep your secret API tokens safe.

In Version Control

We recommend that you do not store your API tokens in version control. It is recommended that you store tokens in an environment file that is never checked into the repository, or directly within the ENV on non-public devices.

linkPublic IDs and Keys

Embedding account, product and policy IDs directly into your product i.e. client-side code is perfectly safe. Inlining your public key is also perfect safe. In fact, you won't be able to communicate with Keygen's API or verify signatures unless you include some of these values, and managing e.g. feature licenses without being able to embed policy IDs wouldn't be feasible.

With that in mind, it is recommended that you use your account ID over your account slug, as unlike your account slug, your ID is unchangable.

Resource IDs are standard v4 UUIDs, resembling the following format:

1fddcec8-8dd3-4d8d-9b16-215cac0f9b52

An account's RSA public key will resemble the following:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPAseDYupK78ZUaSbGw7
YyUCCeKo/1XqTACOcmTTHHGgeHacLK2j9UrbTlhW5h8Vyo0iUEHrY1Kgf4wwiGgF
h0Yc+oDWDhq1bIertI03AE420LbpUf6OTioX+nY0EInxXF3J7aAdx/R/nYgRJrLZ
9ATWaQVSgf3vtxCtCwUeKxKZI41GA/9KHTcCmd3BryAQ1piYPr+qrEGf2NDJgr3W
vVrMtnjeoordAaCTyYKtfm56WGXeXr43dfdejBuIkI5kqSzwVyoxhnjE/Rj6xks8
ffH+dkAPNwm0IpxXJerybjmPWyv7iyXEUN8CKG+6430D7NoYHp/c991ZHQBUs59g
vwIDAQAB
-----END PUBLIC KEY-----

linkAccount Permissions

If you do not want your users to be able to create and manage their own licenses and machines (which could necessitate listening for webhook events) then you should set your account to protected, which will require admin authentication to create and manage all resources, aside from token creation and license validation. Setting your account to protected can be done within your account settings.

Alternatively, you can set individual licenses policies to protected (which by default is inherited from the account's current protected state), which will only disallow users from creating and managing licenses which implement that particular policy and their associated machines, rather than all resources e.g. public user creation, licenses that implement other unprotected policies, etc. You can also set a license to protected, which will disallow machine activation/deactivation; similar to policies, the license's protected attribute is inherited from its policy.

By default, your account is unprotected, which allows user registration as well as the ability for users to manage their own resources.

linkValidation Permissions

If you only need to validate license keys, then you do not need to implement user creation or authentication. The license validate-key action does not require authentication. If you're doing anything else e.g. validating multiple license resources per-user, tracking machines, etc., user authentication or an activation token will be required in order to perform these API operations client-side.

You can add required validation scopes to your policies to e.g. require a machine fingerprint, etc., which helps implement certain license models without the need for any additional server-side logic such as a webhook handler.

linkCrack Prevention

Although all applications are susceptible to cracking (given enough motivation), there are certain things you can do to make cracking harder. Even applications written in a compiled language, such as C, are susceptible to software cracking.

Efforts beyond the prevention measures below have diminishing returns for most software products and time is better spent on legitimate users. Reach out to [email protected] if you need additional anti-cracking measures, we'd be happy to chat with you.

Signature Verification

To help prevent tampering and other types of attacks such as a man-in-the-middle and replay attacks, you may choose to implement license key signature verification, and response signature verification. Both of these verifications harden your software by ensuring the given data originated from Keygen and that the values have not been modified.

The easiest one of those to implement is response signature verification, which can also be used offline with license validation caching.

User Agent Header

We recommend that you supply a custom User-Agent header with all API requests from your software application. You should include your organization name, the application's name, the running version number of the application, the operating system name, in addition to any other information you may find valuable.

Application-Name/1.33.7 (Org-Name) darwin/10.15.5 (macOS Catalina) Apache-HttpClient/4.5.5 (Java/1.8.0_201)

We will use this value to automatically detect cracking attempts. We will notify you of all findings and help you secure your application.

We are currently running a 'pilot' for an AI/ML crack detection product. If this is something your organization is interested in, please reach out to us: [email protected]. We'd love to see if you're a good fit.