Guides & Resources
Equiviq Authentication and Credential Security
- Folders
- Product Guides
- Category
- Information
- Tags
- Equiviq Cloud, Equiviq Core
- Article ID
- FAQ-000008
- Version
- v11
- Visibility
- Public Access
Description
Equiviq Core uses passwordless local sign-in. Users authenticate with an enrolled passkey, an authenticator app code, or a one-time code delivered by email. Equiviq Core does not ask users to create a login password and does not maintain a user password database.
The Control operator console has a separate authentication system for the people who manage licenses and plugin releases. Operators can sign in with an authenticator app or an enrolled passkey. Approving a plugin release requires a fresh authenticator code or a new passkey assertion for that specific release.
How credentials are protected
| Credential | Storage and verification |
|---|---|
| Passkeys | The user’s private key remains with their authenticator. Equiviq stores the credential information needed to verify a signed challenge, with the credential record encrypted in its database. WebAuthn checks the configured site identity and origin. WebAuthn specification |
| Authenticator app secrets | TOTP requires a shared secret on both the authenticator and server. Equiviq encrypts the server’s copy with AES-256-GCM. It records the last accepted time step to reject reuse of a code. |
| Email sign-in codes | Equiviq stores a challenge-bound verifier rather than the code itself. Codes expire after ten minutes, have a per-challenge attempt limit, and are cleared after successful use. |
| Sessions and invitations | Equiviq generates random tokens and stores their hashes in the database. Tokens have expiry or revocation controls; possession of a database hash alone does not provide a usable browser session. |
| Integration API keys | Equiviq integrations generate high-entropy keys, display them when created, and store a hash for subsequent verification. Administrators can revoke a key. |
Encryption keys are held outside the application database. Equiviq Core obtains its application encryption key from server configuration. Control uses a separate operator factor key file, created with restricted file permissions. This separation limits what an attacker can obtain from a database-only compromise.
Session and request protection
Core sessions have a 24-hour absolute lifetime and can be revoked on sign-out. Control operator sessions expire after 12 hours. Session cookies are HTTP-only and use SameSite restrictions; Control sets the Secure flag. Core sets the Secure flag when the request is recognized as HTTPS. State-changing requests use form or CSRF token checks. Core records sign-in attempts and applies a limit by account identifier or IP address over a 15-minute window. Email codes have an additional five-attempt limit per challenge.
Higher-risk Control Actions
A Control operator’s existing session is insufficient by itself to approve a plugin release. The approval workflow checks the release identity and artifact evidence, then requires either a fresh TOTP code or a passkey assertion bound to the active session and release. A successful passkey challenge is consumed so it cannot be reused. Approval is recorded in the Control audit trail and remains separate from the package-signing and publishing steps.
Security boundaries and considerations
IMPORTANT
Passwordless does not mean every sign-in has the same assurance. Core permits email one-time-code sign-in, so the security of that route depends on the user’s email account. An authenticator code is also a shared-secret method and can be phished. Passkeys use public-key cryptography and bind authentication to the site’s identity.
Control requires passkey user verification for operator sign-in and plugin approval. Core currently requests user verification as preferred. Consequently, Core passkey sign-in requests, but does not require, device PIN or biometric verification.
Encryption at rest protects against a database-only disclosure. It cannot protect TOTP or other decryptable application secrets if an attacker also obtains the server’s encryption key and sufficient application access. Key access, backups, rotation, and host security therefore remain part of the deployment’s security responsibilities. This aligns with NIST’s guidance for protecting server-held OTP secrets.
These statements describe Equiviq Core and Control. A connected plugin/integration has its own administrator accounts and authentication controls, which should be assessed separately.
Shared Responsibility and Verification
Equiviq’s authentication controls depend on both the application and its deployment environment. Equiviq Core, the Control operator console, and connected Plugins/integrations each have distinct security responsibilities.
| Area | Equiviq control | Deployment responsibility and evidence to request |
|---|---|---|
| Keys | Selected application secrets are encrypted using keys held outside the application database. | Restrict key access and document storage, backup, recovery, and rotation. Verify the deployed configuration and a rotation test. |
| Sessions | Sessions expire and can be revoked on sign-out. | Verify HTTPS cookie settings, expiry, and administrative session revocation. |
| Recovery | Recovery can restore access when a sign-in factor is lost. | Test identity checks, factor reset, prior-session invalidation, and reenrollment. |
| Audit | Security-sensitive actions are recorded in the applicable audit trail. | Confirm event coverage, access to logs, retention, and export procedures. |
An evaluator should request configuration evidence and witness relevant tests. Encryption of selected application secrets does not mean every database field is encrypted. Database encryption, backups, access controls, monitoring, and retention require separate assessment.
This describes the documented design; it is not an independent audit or certification of the current deployment.
Frequently Asked Questions
Does Equiviq store user passwords? Equiviq’s local sign-in does not use or store user login passwords. Other connected plugins or integrations, manage their own accounts.
Can Equiviq recover a lost passkey? Equiviq does not hold a copy of the passkey’s private key. Account access may instead use another available sign-in method or the implemented recovery flow. Recovery codes are stored as hashes and consumed when used; using one revokes existing Core factors and requires reenrollment.
Why encrypt TOTP secrets instead of hashing them? The server must reproduce the expected authenticator code, which requires access to the shared secret. A one-way hash cannot serve that purpose. Equiviq encrypts the secret and keeps the encryption key outside the database.
What happens if an integration API key is exposed? An administrator can revoke it and issue a replacement. Because the database holds a hash rather than the full key, the existing value cannot be redisplayed from the settings page.
Does passkey approval also sign a plugin? No. Operator approval authorizes the reviewed release. Control’s signing and publication workflow is a separate step.