Security begins with exact boundaries and honest claims.
Nuvquerio separates local secret generation, browser-side vault encryption, server-side account records and administrator controls.
Read the implementation guideSecrets are not supposed to be generated or decrypted by the API.
Implemented controls
The API uses PostgreSQL-backed users, activation-code HMACs, expiring server sessions and scrypt password hashes for administrator credentials. Session cookies are HTTP-only and same-site; the secure attribute depends on the production setting. The service is intended to be exposed through HTTPS and a reverse proxy.
- Rate-limited activation lockout after ten failures per email
- Admin lockout after five failures for a temporary period
- User vault routes are scoped to the authenticated user
Threats we cannot remove
A compromised browser or operating system can read a secret while it is displayed. Phishing, malware, shoulder-surfing, weak passphrases, insecure backups and privileged server compromise remain material risks. Generated secrets are only as safe as the handling and destination policy around them.
- Do not paste secrets into support messages
- Use MFA at the service that receives the credential
- Review logs, backups and access controls as part of operations
Independent assurance
No independent penetration test, SOC 2 report, ISO 27001 certification, FIPS validation or external cryptographic audit is claimed here. Security statements are limited to the current code paths described on this site. A release review, restore drill and independent assessment are needed before assurance statements are made.
- Post-quantum and blockchain private-key generation is not currently offered
- No managed custody or hardware signer is included
- Security incidents and vulnerability reports need an owner and response procedure
Generation boundary
The browser receives random bytes from the platform Web Crypto API. Nuvquerio's output screen is part of the same device that displays and copies the secret, so the security boundary includes the browser, operating system, extensions, clipboard and the person using the screen. 'Generated locally' does not mean 'immune to endpoint compromise.'
- Use a current browser on a trusted device
- Avoid remote-control or screen-sharing sessions during secret handling
- Review extensions and clipboard managers on shared machines
Session and account boundary
The API authenticates an email and password, issues a time-limited session and checks the user's role before serving vault operations. Administrator code issuance is a separate role. Account authentication is not the vault encryption key, and administrators cannot read a user's encrypted vault through the intended CRUD endpoints.
- Sessions are server-side and expire after 12 hours
- User vault access is filtered by authenticated user ID
- A disabled account should no longer access protected routes
Questions a serious review should still ask
A credible review should inspect the complete browser bundle, dependencies, deployment headers, TLS setup, database permissions, backup access, log retention, restore process and incident handling. The source code description is useful evidence, not an independent assessment, and a static website cannot prove what the live host is configured to do.
- Review the exact deployed release and its dependencies
- Test role separation and cross-account access boundaries
- Commission an independent security assessment before high-risk use
Security is a workflow, not a label.
Review the implementation boundaries