How credentials are stored

You hand Pressbotics a credential to your website. That deserves a precise answer about what happens to it, not a reassuring adjective.

Encrypted at rest

WordPress Application Passwords are encrypted with AES-256-GCM before they are stored. GCM is authenticated encryption: tampering with the stored ciphertext makes decryption fail rather than silently returning something else.

The key lives with the rail

The encryption key is held only by the publishing rail — the component that talks to WordPress. It is not in the dashboard, not in the database, and not in any client bundle. Reading a credential requires both the stored ciphertext and that key, and nothing else in the system has both.

The practical consequence: we cannot read your WordPress password. There is no support screen that shows it, and there is no way for us to recover it for you. If you lose it, you create a new Application Password in WordPress and reconnect.

Never in a response, never in a log

• Credentials are decrypted in memory at the moment of a request and are never returned to a browser or an agent.
• No API response contains a credential, in any field, in any shape.
• Errors and logs record what happened — wp_auth_failed, for example — never the value that failed.
• Agent keys are stored as hashes. The key is shown once at creation and cannot be shown again, because we do not have it.

Why Application Passwords

An Application Password is revocable independently of your WordPress login, scoped to REST access, and visible in your own wp-admin. You can revoke ours at any time without changing your password or affecting anything else. Do that in Users → Profile → Application Passwords.

Reporting a problem

If you believe a credential has been exposed, revoke it in WordPress first — that is immediate and does not depend on us — then email info@pressbotics.com.