Security
Tenant isolation, authentication, encryption, and platform security controls
The platform implements security controls at multiple layers to protect tenant data, prevent unauthorized access, and ensure safe operation.
Three-layer tenant isolation
| Layer | Mechanism | What it prevents |
|---|---|---|
| Workspace boundary | All resources (accounts, proxies, bots, billing) are scoped to a workspace ID. Every query includes a WHERE workspace_id = ? clause enforced by the data access layer. | One workspace accessing another's data via API or UI. |
| Per-account runtime | Each account runs in its own OS process with its own session file, TLS fingerprint, MTProto connection, and auth key. Processes are sandboxed with cgroups. No connection multiplexing across accounts. | An account's Telegram session being hijacked or observed by another account on the same host. |
| Per-account proxy | Each account is pinned to a single dedicated proxy. Proxy credentials are never shared across accounts. IP rotation is per-account only. | Telegram linking accounts via shared IP addresses. |
| Tenant-to-tenant rental | The times_allocated counter is checked at allocation time. Only accounts with times_allocated = 0 are rented from the pool. After release, the account row is retired. | A second tenant receiving an account previously used by a different tenant. |
| Active-session enforcement | Every 6 hours, the platform checks each rented account against Telegram's list of active sessions. Unknown sessions trigger a notification with approve/terminate options. | Unauthorized access to a rented account through other means. |
| Hidden-peer redaction | Messages from Telegram's peer ID 777000 are redacted at ingestion time for rented accounts. The redaction happens at the storage layer before the message reaches the inbox. | A rental holder reading login codes for the underlying phone number. |
Authentication
Password requirements
| Requirement | Value |
|---|---|
| Minimum length | 10 characters |
| Character mix | Must include uppercase, lowercase, digit, and a symbol |
| Storage | bcrypt, work factor 12 |
| Maximum attempts (login) | 10 per minute per IP |
| Lockout duration | 15 minutes after exceeding max attempts |
Two-factor authentication (TOTP)
| Setting | Value |
|---|---|
| Algorithm | TOTP (RFC 6238), SHA-1, 30-second window |
| Backup codes | 8 codes, each valid once |
| 2FA attempt limit | 10 attempts per 15 minutes per IP |
| Lockout duration | 15 minutes after exceeding max attempts |
Brute-force protection
The platform implements IP-scoped rate limiting:
| Endpoint | Limit | Window |
|---|---|---|
| POST /auth/login | 10 requests | 1 minute per IP |
| POST /auth/2fa | 10 requests | 15 minutes per IP |
| POST /auth/register | 3 requests | 10 minutes per IP |
| POST /auth/forgot-password | 5 requests | 30 minutes per email |
| POST /auth/reset-password | 5 requests | 30 minutes per token |
When a rate limit is exceeded, the platform returns HTTP 429 with a Retry-After header indicating the number of seconds to wait. After 3 consecutive rate-limit events, the IP is blocked for 60 minutes.
Encryption
| Key hierarchy | Algorithm | Rotation |
|---|---|---|
| Root key | AES-256, generated in KMS | Annually |
| Workspace key | HKDF-SHA256 derived from root key + workspace ID | Annually |
| Account key | HKDF-SHA256 derived from workspace key + account ID | Quarterly |
| Session key | Ephemeral, generated per MTProto connection | Per connection |
| Database encryption key | AES-256 | Quarterly |
| Backup encryption key | AES-256 | Quarterly |
All encryption keys are managed through the platform's KMS infrastructure. Keys are stored separately from the data they protect, and access to keys is logged and audited.
Device-fingerprint matching
The platform maintains a device fingerprint for each account based on the session metadata Telegram provides (device model, system version, app version, system language, and IP geolocation).
| Situation | Action |
|---|---|
| Fingerprint unchanged | Normal operation |
| IP geolocation changes (new country) | Email notification, optional mid-session 2FA challenge |
| Device model or system version changes | Email notification, no disruption |
| Multiple simultaneous connections from different geos | Flagged for review, accounts with above 50 health score auto-kill the new session |
| Unknown session detected in active-session scan | Notification with approve/terminate options |
SSRF protections
All outbound requests that the platform makes on your behalf (webhook calls, proxy connectivity tests, avatar fetches) are subject to SSRF protections:
- Requests to private IP ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.0/8,169.254.0.0/16) are blocked at the network layer. - DNS resolution is verified. If a domain resolves to a private IP, the request is blocked.
- Redirects are followed but re-verified against private IP blocks at each redirect hop.
- Webhook URLs must use HTTPS (TLS 1.2+). HTTP webhooks are refused.
- Request timeout is 10 seconds total (including redirects).
Bot webhook verification
Bot webhook callbacks include a signature header (X-TelegramOS-Signature) that allows you to verify the request came from the platform. The signature is an HMAC-SHA256 of the request body, keyed with the bot's API token. See the Bots page for verification code examples.