Security
What we do, in plain language.
Licensing infrastructure only works if you can trust it. This page lists the measures that are actually implemented in Aroli today - no certifications we don't hold, no promises nobody can keep.
Security measures by area
01
Credentials
- Argon2id for dashboard and end-user passwords
- Session tokens and API keys are 256-bit random values stored as SHA-256 hashes
- License keys stored as HMAC-SHA256 verifiers; plaintext shown once at generation
- Dashboard session cookie is HttpOnly
02
Transport & integrity
- Client API responses signed with a per-application Ed25519 key
- Signature covers timestamp, client nonce and body to detect tampering and replays
- Signing keys can be rotated; responses carry the key ID
- Webhook deliveries signed with HMAC-SHA256 and a per-endpoint secret
03
Data at rest
- Signing private keys, webhook secrets and MFA secrets encrypted with AES-256-GCM
- Hardware IDs stored as salted hashes, per application
- Secret API keys are never retrievable after creation
04
Access control
- Tenant isolation checks on every request
- Roles: Owner, Admin, Developer, Support, Viewer
- Optional TOTP MFA with one-time recovery codes
- Scoped management API keys, bound to one application
05
Abuse resistance
- Rate limits on sign-in, registration, redemption and validation
- Atomic license redemption and activation - no double-redeem under concurrency
- Server-enforced device and activation limits
- Webhook targets must be public HTTPS; private and loopback addresses are rejected
06
Accountability
- Audit log of administrative actions
- Request IDs on every API response
- Idempotency keys for management API writes
Limits, honestly
What Aroli can’t do for you
Device fingerprints are supplied by the client, so a determined attacker can spoof them. Aroli enforces device and activation limits on the server, signs every response and keeps secrets out of your binary - but no service can make software running on someone else’s machine uncrackable. We'd rather tell you that up front.
Practical advice
- Never ship a secret management key (ak_…) inside client software. Only the public app ID belongs there.
- Always verify response signatures - the official SDKs do this for you.
- Treat the hardware ID as a hint, not proof. Use device limits to make sharing inconvenient, not impossible.
- Check entitlements on your server too, wherever your product has a server-side component.
- Watch webhooks and the audit log for unusual activity, and ban or revoke quickly.
Every measure at a glance
Argon2id for every password
Dashboard accounts and your end users alike. Plaintext passwords are never stored.
Tokens stored only as hashes
Session tokens and API keys are random 256-bit values. We keep only their SHA-256 hash, so stored values can't be used to sign in.
License keys shown once
Keys are stored as HMAC verifiers. You see the plaintext once when generating them; afterwards only a short hint remains.
Signed responses, per-app keys
Each application has its own Ed25519 key pair. Client API responses are signed, and keys can be rotated.
Encryption at rest for secrets
Signing keys, webhook secrets and MFA secrets are encrypted with AES-256-GCM before they reach the database.
Optional two-factor sign-in
Dashboard accounts can enable TOTP-based MFA with one-time recovery codes.
Rate limiting
Sign-in, registration, redemption and validation endpoints are rate-limited per application and IP address.
Tenant isolation on every request
Each request is checked server-side against your organization and application before any data is read or changed.
Role-based access
Owner, Admin, Developer, Support and Viewer roles control who can change what in your organization.
Audit logs
Administrative actions are recorded with who did what and when, so changes are traceable.
Signed webhooks, guarded delivery
Deliveries carry an HMAC-SHA256 signature. Endpoints must be public HTTPS; private and loopback addresses are rejected.
Request IDs everywhere
Every API response carries a request ID, so any issue can be traced end to end.
Found a vulnerability?
Please report it privately to [email protected] with the subject “Security report” and enough detail to reproduce it. Please don't access other customers' data or degrade the service while testing. See also our Acceptable Use Policy.
Security that stays out of your way.
Create an application, connect an SDK and issue your first license key. The free plan has everything you need to build and test your integration.