How QCSB Protects Passwords, Private Keys, and Provider Secrets

This article explains encrypted secret storage, connection isolation, administrator-only configuration surfaces, and operational rules for avoiding credential disclosure in logs, support requests, or frontend HTML.

What you need to know

  • Provider credentials are stored per connection and are not sent back to ordinary frontend users. Secret-bearing error text is sanitized before it is shown or persisted for user-facing diagnostics.
  • Private Connections use separate per-user credentials/tokens; administrator OAuth credentials and another user’s private credentials are not silently reused.
  • Basic includes Local storage and the first active Workspace. Pro adds FTP/SFTP, multiple Workspaces, advanced permissions, and background continuation. Max/All Access adds Google Drive, OneDrive, Private Connections, Recovery Vault management, and bulk operations.
  • A plan gate decides whether a feature exists at the current Effective tier. Joomla access and QCSB permission rules separately decide whether a particular user may use that feature.
  • My Private Storage requires Max/All Access and supports user-owned FTP, SFTP, Google Drive, and OneDrive connections. Local storage remains administrator-created only.
  • Private connection ownership is enforced server-side. Private connections cannot be inserted into administrator shared Workspaces even if request/database values are manipulated.

Secret-handling rules

  • Administrator provider secrets are stored with the Storage Connection secret service rather than being exposed to frontend Workspace users.
  • Private Storage secrets/tokens are stored in the owner-scoped private-connection context, separate from shared administrator credentials.
  • Password/client-secret/private-key form fields do not intentionally repopulate saved plaintext secrets into routine edit screens; leaving a saved-secret field blank can preserve the existing secret where the form indicates that behavior.
  • OAuth access/refresh tokens are bound to the intended connection through protected state/PKCE flows.
  • Sanitized error handling removes secret-bearing values before ordinary user-facing diagnostics/support evidence is persisted or displayed.

Operational rule

Treat the Joomla Administrator and database/host as sensitive systems even with these controls. Do not paste passwords, client secrets, OAuth tokens, SFTP private keys/passphrases, or unrestricted private filesystem paths into public tickets, forum posts, screenshots, or documentation examples.

Verify the result

  • The owner can see/use the private connection.
  • Another normal Joomla user cannot see or use that owner’s private connection.
  • Private connections do not appear as selectable connections in administrator shared Workspaces.

Important limits and mistakes to avoid

  • Do not copy administrator or another user’s provider credentials into a private connection as a shortcut; private connections are intentionally isolated.

Troubleshooting

  • Keep passwords, OAuth secrets/tokens, private keys, and unrestricted private paths out of public screenshots and support posts.

Community Discussion

For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.