Think of your API credentials as valuables in a safe. HuxxConnect always locks the safe — every credential is encrypted with AES-256-GCM before it touches the database. The encryption tier answers a different question: where do you keep the key to the safe?

• Standard — the key hangs on a hook next to the safe. Convenient, and the safe travels with its key.
• Advanced — the key stays in your pocket. Someone who steals the safe still can’t open it.
• Locked — the key is built into the wall of the house. The safe can never leave the building.

That is the entire difference between the tiers. Same cipher, same encrypted storage — different key location, and therefore a different threat model and a different portability story.

flowchart LR
    subgraph Standard
        A[Encrypted credentials<br>in database] --- B[Key stored<br>in database]
    end
    subgraph Advanced
        C[Encrypted credentials<br>in database] --- D[Key in<br>wp-config.php]
    end
    subgraph Locked
        E[Encrypted credentials<br>in database] --- F[Key derived from<br>WordPress salts]
    end

What every tier shares#

Regardless of tier, credentials are encrypted at rest with AES-256-GCM (an authenticated cipher — tampered ciphertext fails to decrypt rather than producing garbage). They are never stored decrypted; decryption happens in memory when needed — sending requests, admin display, tier switches — and credential values only leave the site if you explicitly include secrets in an export. The tier is selected under HuxxConnect → Settings, in the Security card’s Encryption Key Source section. Switching tiers re-encrypts all stored credentials with the new key automatically — see Choose an Encryption Tier.

Standard: key stored in the database#

On the Standard tier, HuxxConnect auto-generates a random 64-character key and salt the first time you load the admin after activation and stores them in its own settings row in the database. (If HUXX_CONNECT_ENCRYPTION_KEY constants already exist in wp-config.php on a first install, the plugin adopts them and starts on the Advanced tier instead.)

Threat model. Credentials are protected against casual inspection — anyone browsing the database, reading a partial export, or seeing a credentials column in a log sees only ciphertext. However, because the key lives in the same database, an attacker who obtains a complete database dump (including the settings table) has both the safe and the key. Standard raises the bar; it is not a defense against full-database theft.

Portability. This is the tier’s strength. Because the key travels inside the database, a site migration or clone carries everything needed to decrypt — the safe and its key move together. The Environment Lock still pauses decryption after a move until you confirm the move was intentional, but no key material is lost.

Advanced: key in wp-config.php#

On the Advanced tier, you define two constants in wp-config.php:

define( 'HUXX_CONNECT_ENCRYPTION_KEY', 'paste-your-key-here' );
define( 'HUXX_CONNECT_ENCRYPTION_SALT', 'paste-your-salt-here' );

The settings page generates real values for you (Generate Keys), and once the constants are verified the key is never stored in the database. The Settings UI describes this tier as the most secure option, and that framing is about separation: the key lives in the filesystem, the ciphertext lives in the database.

Threat model. A database-only theft — SQL injection, a leaked backup, a compromised database server — cannot decrypt your credentials, because the key isn’t in the database at all. An attacker would need filesystem access to wp-config.php as well, and an attacker with filesystem access has already won far more than API credentials.

Portability. Manual but straightforward: copy the two constants from the source server’s wp-config.php to the destination server’s wp-config.php. When the constants are present on the new server, HuxxConnect verifies them and unlocks automatically — no passphrase needed. If you migrate the database without copying the constants, credentials stay locked until you add them (the ciphertext is intact; only the key is missing).

Locked: key derived from WordPress salts#

On the Locked tier, HuxxConnect derives its encryption key from the WordPress authentication salts (LOGGED_IN_KEY and LOGGED_IN_SALT in wp-config.php). It stores no key of its own anywhere — switching to this tier deletes the stored key.

Threat model. Like Advanced, the key material lives outside the database, so a database-only theft cannot decrypt credentials. Unlike Advanced, there is no HuxxConnect-specific secret to manage — the key is whatever this server’s WordPress salts are.

Portability. None, by design. WordPress salts are unique per install, and nearly every migration workflow (host moves, staging clones, salt rotation after an incident) generates fresh salts. New salts mean a new derived key, and the old ciphertext becomes permanently undecryptable. After a migration, HuxxConnect detects this, skips the unlock ceremony (there is nothing to unlock), and asks you to re-enter credentials on each API page. Choose Locked only for a site that will never move — or where “re-enter the credentials after a move” is an acceptable cost for zero key management.

The trade-off at a glance#

There is no universally correct tier. Standard optimizes for portability, Advanced for separation with manual portability, Locked for separation with zero portability. The one firm recommendation: don’t pick Locked casually — the Settings page shows a warning before the switch precisely because the choice has migration consequences.

See it in practice#

• Choose an Encryption Tier — switching tiers and what re-encryption does
• Environment Lock Explained — the companion mechanism that detects when your site moves
• Move a Site with Locked Credentials — the migration playbook
• Store Credentials Outside the Database — per-credential constants, a complementary technique