Security for Creator Credentials

Encryption at rest

Each creator credential is encrypted independently with AES-256-GCM before it is written to MySQL. Every encryption uses a fresh random salt and initialization vector. HKDF-SHA-256 derives a separate key for the creator, credential type, and encryption version.

The creator ID and credential field are authenticated as additional data. Moving ciphertext to another creator or field causes authentication to fail. The authentication tag also detects modification or corruption.

Key separation and versioning

The database stores versioned ciphertext, salt, initialization vector, authentication tag, and encrypted value—not the master encryption key. The master key remains in server-side environment configuration. A database-only disclosure is therefore insufficient to decrypt credentials.

Legacy credentials are migrated to the current context-bound format when database initialization runs. Versioning allows future cryptographic upgrades and planned key rotation.

Limited exposure

• Creator-profile API responses expose only whether a key is configured, never its plaintext value.
• Credentials are decrypted only inside server routes that need to contact Tebex or verify a webhook.
• Database failures fail closed in production instead of switching to temporary memory storage.
• Creator-only routes enforce role authorization and sessions enforce expiration centrally.

Account and purchase protection

Passwords use salted scrypt hashes. Session and record identifiers use cryptographically secure randomness. Cfx.re basket state is signed and verified server-side, and imported purchases must match the account's verified Cfx.re identity.

What creators should do

• Use dedicated Tebex credentials with the minimum permissions needed.
• Never send API keys through chat, screenshots, tickets, or public repositories.
• Rotate credentials immediately after suspected exposure or staff-access changes.
• Use unique account passwords and protect hosting and Tebex accounts with multi-factor authentication.
• Keep the webhook endpoint secret separate from other API credentials.

Responsible reporting

If you believe a credential or account is at risk, rotate the affected key first, disconnect the integration if necessary, and contact Escalative support with non-sensitive reproduction details. Never include a live credential in a report.

Honest limitations

No system can guarantee absolute security. Server operators with access to the running application and its master encryption configuration may be able to decrypt credentials. Escalative therefore combines encryption with authorization, redacted API responses, secure sessions, operational access controls, and creator-side key rotation.