Encryption
SonicSaaS encrypts all sensitive data at rest using industry-standard cryptography. Credentials are never stored in plaintext and are only decrypted at the moment they are needed.
What Is Encrypted
| Data | Encryption | Key |
|---|---|---|
| Device credentials (firewall admin passwords) | AES-256-GCM | DEVICE_ENCRYPTION_KEY |
| Integration API keys (ITGlue, ConnectWise, etc.) | AES-256-GCM | DEVICE_ENCRYPTION_KEY |
| FTP server passwords | AES-256-GCM | DEVICE_ENCRYPTION_KEY |
| MFA secrets (TOTP) | AES-256-GCM | AUTH_ENCRYPTION_KEY |
| Configuration backup files | AES-256-GCM | DEVICE_ENCRYPTION_KEY |
| User passwords | bcrypt (one-way hash) | N/A — not reversible |
| MFA recovery codes | SHA-256 (one-way hash) | N/A — not reversible |
How Credential Encryption Works
Device credentials are encrypted using AES-256-GCM, a symmetric encryption algorithm that provides both confidentiality and tamper detection.
- At storage time: A fresh random initialization vector (IV) is generated for each credential, the credential is encrypted, and an authentication tag is produced to detect tampering
- At rest: The encrypted credential, IV, and authentication tag are stored together in the database — the plaintext credential is never saved
- At use time: When the platform needs to connect to a firewall, the credential is decrypted in server-side memory, used for the API call, and then discarded
This means credentials exist in plaintext only during the brief window of an active API call to the device.
Key Management
SonicSaaS uses separate encryption keys for different data classes:
DEVICE_ENCRYPTION_KEY— encrypts device credentials, integration keys, and backup filesAUTH_ENCRYPTION_KEY— encrypts MFA secrets (separate from device credentials for key compartmentalization)
Both keys are 32-byte (256-bit) values stored as environment variables. They are never committed to source control, never logged, and never included in container images.
Generating keys
Generate a secure encryption key:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"Key security
- Keys are validated at application startup — invalid keys prevent the application from starting
- Keys exist only in your
.envfile or secrets manager — they never travel over the network - The encryption module is protected by a server-only import guard, preventing it from being accidentally included in client-side code
Credential Lifecycle
The credential lifecycle is designed around the principle of minimum exposure:
- User enters credentials in the web interface (HTTPS-encrypted in transit)
- Server encrypts immediately — plaintext never touches the database
- Stored encrypted — database contains only ciphertext
- Decrypted on demand — only when connecting to a device, in server memory
- Discarded after use — no credential caching, no persistent plaintext
- Never sent to the client — database queries that return device data explicitly exclude credential columns
Backup File Encryption
Configuration backup files downloaded from firewalls are encrypted before being written to disk. The encrypted format includes a header, IV, authentication tag, and ciphertext — ensuring backups at rest are protected even if the storage media is compromised.