How QCFUM Protects Passwords, Invite Tokens, and Sensitive Account Actions

QCFUM 2.0.4 is designed so delegated managers do not need to see reusable secrets. Generated passwords are delivered privately to the affected user, Invite Link records store token hashes rather than the raw link token, and sensitive actions are protected by Joomla session and authorization checks.

Generated Passwords Stay Private

When QCFUM creates a password on behalf of a user, it generates the temporary password with Joomla’s User helper, saves the account through Joomla’s User API, marks the account to require a reset, and sends the temporary password through the appropriate user email template.

The Frontend User Manager’s password-reset action follows the same boundary: the manager triggers the reset, but QCFUM reports that the password was emailed to the user rather than displaying the generated password back to the manager.

Invite Links Store a Hash

QCFUM generates a random Invite Link token and places the raw token only in the link sent to the recipient. The invitation record stores a hash in token_hash (or the pending-token hash during applicable lifecycle transitions).

When the recipient later presents the link, QCFUM hashes the submitted token and looks up the matching stored hash. The invitation table is therefore not intended to be a plaintext token directory.

Sensitive Forms Carry a Joomla Form Token

QCFUM POST forms render Joomla’s current form token. Sensitive handlers also recheck the acting user’s QCFUM action permission, current Effective tier, workflow state, and target protections before applying account changes.

A visible button is never the full authorization boundary. A forged or stale request still has to pass the server-side checks for that action and target.

Practical Security Rules

  • Do not ask frontend managers to copy generated temporary passwords.
  • Do not log or publish raw Invite Link tokens.
  • Do not paste passwords, Invite Links, session tokens, entitlement tokens, or private credentials into support tickets or screenshots.
  • Use HTTPS for the Joomla site so account setup and authenticated actions are protected in transit.
  • Keep Joomla and QCFUM current so session, user, and security fixes are applied.

What an Administrator Should Verify

  1. Create one safe test account through a workflow that generates a password and confirm the password is received privately by the user.
  2. Create one test Invite Link and confirm only the recipient-facing link contains the usable raw token.
  3. Try a sensitive operation with a staff account that lacks the required QCFUM action and confirm it is denied.
  4. Try an allowed operation against a protected target and confirm the target protection still wins.

Community Discussion

Want to compare Joomla user-management safeguards, share practical QCFUM configuration ideas, or discuss how other administrators delegate frontend workflows? Visit the QC Frontend User Manager Community. For private support, bug reports, account-specific entitlement problems, or feature requests, use the QuantaCade support system.