How Laboratory Access Codes and Cookies Are Protected

QCUL protects the laboratory access secret and gate cookie as sensitive credentials rather than storing or exposing them as ordinary plaintext state.

Current secret handling

• Gate access code and cookie value use encrypted storage with AES-256-GCM and a site-derived key.
• Hashes are stored/used for verification so the system can validate a secret without treating plaintext as the normal persisted comparison value.
• The browser cookie is HttpOnly, SameSite=Strict, and scoped to the laboratory path.
• Automated evidence can recover/repair the run-specific gate cookie securely when needed rather than publishing it into the page.

Administrator responsibilities

Do not put the access code or private lab URL in public tickets/forums, screenshots, documentation examples, or shared chat channels. If exposure is suspected, remove/refresh the lab so the old access context is no longer authoritative.

Cookie is not the only layer

The gate works with rewrite rules, robots/cache headers, lab runtime identity, and production URL protection. Weakening any one layer reduces the confidentiality margin of a production-derived copy.

Defense-in-depth principle

How Laboratory Access Codes and Cookies Are Protected is one layer in QCUL’s security model. Keep Joomla ACL, CSRF tokens, private gate/storage, laboratory identity, runtime authorization, side-effect quarantine, production Super User checks, and careful handling of production-derived evidence together rather than weakening another control to make one workflow more convenient.

Community Discussion

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