Security

How Licento protects what it holds.

A licensing service holds the keys to what you sell. This page describes how this software protects them — as it is built, not as a list of promises.

Licence keys

A licence key is stored only as an HMAC-SHA-256 digest, under a secret kept in the server’s environment rather than its database. A copy of the database alone does not contain a usable key.
The readable key is shown once, when it is issued, and is never written to a log.
A key bought through a payment waits for its email encrypted, and is removed once it has been delivered. The background job that sends it carries only a reference to it.
A key is an entitlement to a product. It is never a way into anybody’s account.

Signed answers

Every licensing answer is signed with Ed25519. Your software verifies it with a public key and holds nothing that could produce a signature.
Private signing keys are encrypted at rest with the application key and are never shown after they are created.
An answer that withholds an entitlement is signed as well, so a denial cannot be altered into a grant.

Accounts and sign-in

Passwords are hashed with bcrypt and must be at least twelve characters. They are never sent to anybody by email.
Two-factor authentication with an authenticator app, with single-use recovery codes. An organization can require it for the roles that need it.
Email addresses are confirmed before a workspace can be used.
The password is asked for again before anything that cannot be undone, such as revoking a key or deleting a webhook.
Repeated failed sign-ins are slowed down and recorded.

Organizations kept apart

Every licensing record belongs to exactly one organization, and every query is limited to the organization the request was made for.
Which organization that is comes from the signed-in session or the API credential — never from anything in the request a caller could change.
A query made without an organization established is refused rather than answered for everybody.

API and webhooks

API credentials are limited to the operations they are given, and their secrets are stored as keyed digests.
Requests that create things accept an idempotency key, so a retry after a timeout cannot create a second licence.
Webhooks are signed with HMAC-SHA-256 and a timestamp, so your server can tell they came from here and are recent.
Webhook addresses on private or internal networks are refused, and the address is checked again at the moment of delivery.

Payments

Card details are entered on the payment provider’s own pages and never reach this service.
A subscription or an order changes only when the provider’s signed notification arrives — never because a browser returned from a checkout page.
Each notification is applied once, and one that arrives late cannot overwrite a newer one.

The service itself

HTTPS, with Strict-Transport-Security in production.
A content security policy that allows scripts only from this site, protection against cross-site request forgery on every form, and pages that cannot be framed by other sites.
Rate limits on sign-in, on the licensing API and on forms like the one on the contact page.
An audit trail of security-relevant changes: sign-ins, keys, roles, settings and licences.
Daily database and release-file backups, on the operator’s server, with an optional encrypted copy elsewhere.

Found a problem?

If you think you have found a security issue, tell us privately before telling anybody else, and give us a reasonable time to fix it.

Use the contact form

What this page is not

It describes what the software does. It is not a certification: no SOC 2, ISO 27001 or PCI DSS assessment is claimed here. How the service is hosted and operated — the server, its updates, who can reach it — is the responsibility of whoever runs this installation.