Why QCUI Stores Only a SHA-256 Hash of the Handoff Token

Why QCUI Stores Only a SHA-256 Hash of the Handoff Token is a deliberate QCUI 1.0.03 behavior that protects administrator access, target-account safety, or the integrity of the one-time impersonation handoff.

Hash-at-rest design

The #__qcloginasuser_tokens.token_hash column stores a unique 64-character SHA-256 digest. When the frontend submits the raw token, QCUI hashes it again and looks for the corresponding unused, unexpired row.

What a database reader does not get

The database row does not expose the raw one-time secret that was placed in the handoff form. This reduces the value of reading that table during the brief validity window.

Not password hashing

This mechanism is for random one-time token lookup, not customer password storage. QCUI never stores the target password at all.

Security boundary

The controls described for Why QCUI Stores Only a SHA-256 Hash of the Handoff Token are complementary. Super-User authorization does not make a reusable token safe; a one-time token does not make Shared Sessions safe; and a visible banner does not make state-changing customer actions harmless. Preserve the complete 1.0.03 security model rather than removing individual checks for convenience.

Community Discussion

Want to compare support workflows, share practical tips, or discuss how you use this QCUI feature? Visit the QC User Impersonation Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.