Credentials for connected services are never held in plaintext on the account row. They are encrypted with AES-256-GCM under an application key, stored in a versioned format with a random per-encrypt initialisation vector and an authentication tag, so tampering fails the decrypt instead of returning garbage. Legacy plaintext rows predating the module are detected by the missing version sentinel and re-written on the next save.
Also called: are my passwords safe · encryption · data security · stored credentials · api keys · encrypted credentials · API key storage · password encryption · secrets at rest
- 1Encrypt with AES-256-GCM, random 12-byte IV per operation, 16-byte auth tag
- 2Store as a versioned blob with a prefix sentinel
- 3Reads detect the sentinel; anything without it is treated as legacy plaintext and queued for re-write
- 4Key rotation bumps the version and dual-reads for one deploy cycle
Connecting a CRM, an estimating system and a payment processor means handing over credentials that would let a stranger message every customer in the business and see the money. Stored plainly, a single read — a leaked backup, a mis-set permission, anyone holding an administrative key — would give up every builder's connected accounts at once. Those secrets are encrypted before they are stored, using the kind that fails loudly if anyone tampers with it rather than quietly returning nonsense, and the stored form carries a version so keys can be rotated later without taking the platform down for a day.
- Plaintext third-party credentials turn any single database read into a total compromise
- Silent decryption of tampered data is worse than a failure
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →