An extension-first password manager for Chrome and Firefox. VeyraKey detects login and signup forms, securely fills saved data, and syncs authenticated ciphertext through the user's own Google Drive.
Quick start · Capabilities · Architecture · Security · Documentation
Warning
VeyraKey is a portfolio-grade release candidate, not an independently audited password manager.
Do not use pre-release builds for irreplaceable secrets. Public release still requires the external
evidence listed in release/external-gates.json.
Version 0.10.0 is distributed as a release candidate for developer installation. The archives
are produced by the verified release pipeline, but they are not yet signed or reviewed by the Chrome
Web Store or Firefox Add-ons.
| Download | Intended use | SHA-256 |
|---|---|---|
| Chrome MV3 extension | Chrome, Edge, Brave, and other Chromium browsers | dee56740c9d21d419c627661c8dfeb01eb1b68a90e2cebf3f86ac1564872616b |
| Firefox MV3 extension | Temporary developer installation in Firefox | 3b47da0021b980bdc7a3163eee4ca3132f22e2bdf6d7595141a653c4908458af |
| Reviewable source archive | Source review and browser-store submission | 9166c04658f55fcf422af5c0daea0dd8f04a175d93526ff9eaf0f26953ee6ac7 |
| Release manifest | Artifact inventory and automated-gate evidence | See the checksums inside the manifest |
| CycloneDX SBOM | Dependency and supply-chain review | See the release manifest |
- Download and extract the Chrome ZIP.
- Open
chrome://extensions. - Enable Developer mode.
- Choose Load unpacked and select the extracted folder containing
manifest.json. - Pin VeyraKey from the browser toolbar.
- Download and extract the Firefox ZIP.
- Open
about:debugging#/runtime/this-firefox. - Choose Load Temporary Add-on and select
manifest.jsonfrom the extracted folder.
Firefox removes temporary add-ons when the browser restarts. A permanent one-click installation will be offered only after Mozilla signing; Chrome Web Store and Firefox Add-ons availability remain tracked external release gates.
The browser extension is the product: it follows users across websites, recognizes authentication and registration flows, saves or updates credentials, offers private email aliases, and releases matching secrets only after the required local authorization. The web application is a companion development and recovery surface—not the primary user experience.
Most password-manager demos stop at encrypted CRUD. VeyraKey treats the browser, cloud provider, autofill surface, device unlock flow, revision history, and release pipeline as separate trust boundaries.
| Principle | What it means in practice |
|---|---|
| Zero knowledge | Master passwords, Recovery Kits, plaintext records, vault keys, and device PRF outputs stay in the client. |
| Bring your own storage | Google Drive stores encrypted vault state in its private app-data area; it cannot decrypt the payload. |
| Local-first | A vault can be used without a cloud account. Cloud connection is optional and reversible. |
| Origin-bound autofill | Credentials are released only to an exact saved origin after the required local authorization. |
| Recoverable by design | Encrypted backups and Recovery Kits exist; a server-side reset or escrow key does not. |
VeyraKey is designed to stay available from the browser toolbar and directly beside relevant form fields. Users should not need to keep a separate web tab open.
- Visit a login or signup page.
- Select a saved account, generated password, identity value, or private email suggestion.
- Authorize with the active unlocked session, Touch ID/biometrics when enrolled, or the master password fallback.
- VeyraKey fills only the recognized fields for the exact current origin.
- After a successful login or registration, accept the concise save/update prompt if the vault record changed.
The extension popup provides the complete vault library, security findings, passkey/TOTP metadata, private-email configuration, cloud sync, backup/import tools, and device security settings.
- Encrypted logins, secure notes, identity profiles, and payment cards.
- Exact-origin username/password suggestions with guarded fill and submit behavior.
- Automatic save and update prompts that suppress unchanged duplicate credentials.
- Readable strong-password generation on recognized registration and password-change forms only.
- Identity and address autofill; payment-card support intentionally excludes stored CVV and purchase submission.
- Local TOTP generation and QR import for authenticator codes.
- Automatic signup-only email aliases on recognized HTTPS registration forms.
- Provider-free plus addressing, generated per site with a random suffix.
- Optional SimpleLogin or Addy.io integration using the user's own encrypted provider token.
- Aliases are persisted only when the matching credential save is accepted, then follow normal encrypted sync.
- Device-only local encrypted vault with no account requirement.
- Google-connected encrypted vault using Drive's private
appDataFolderscope. - Restore on another device with the same Google account and the existing vault master password.
- Account switching, cloud disconnect, encrypted backup, import preview, and atomic restore boundaries.
- Immutable item revisions, history inspection, and restore-as-new-revision semantics.
- Weak, reused, and aged-password analysis performed locally.
- Optional Pwned Passwords range checks that send a five-character SHA-1 prefix, never the password.
- WebAuthn PRF device unlock where the browser/authenticator combination supports it.
- Per-device enrollment status and revocation.
- Encrypted single-item sharing with a separate secret and bounded expiry.
VeyraKey does not claim to replace the browser or operating system as a native passkey provider.
WebAuthn ceremonies and passkey private keys remain with the platform authenticator. The vault can
store bounded public passkey references and related account metadata, while TOTP secrets are
encrypted and generated locally. See
docs/39-private-email-and-passkey-boundary.md.
| Local vault | Google-connected vault | |
|---|---|---|
| Account required | No | Google authorization |
| Source of truth | This browser profile | Encrypted Drive app data + local cache |
| Cross-device restore | Encrypted backup + Recovery Kit | Same Google account + vault unlock material |
| Cloud plaintext access | Not applicable | None by design |
| Can disconnect later | Not applicable | Yes; the local encrypted vault remains |
flowchart LR
Page["Untrusted web page"] -->|schema-validated request| Content["Isolated content script"]
Content -->|exact origin + field descriptors| Worker["MV3 service worker"]
Popup["React vault UI"] --> Worker
Worker --> Session["Short-lived unlock session"]
Worker --> Vault["Vault service"]
Vault --> Crypto["Argon2id · HKDF · XChaCha20-Poly1305"]
Vault --> IDB["Encrypted IndexedDB cache"]
Vault --> Sync["Immutable revision sync"]
Sync --> Drive["Google Drive appDataFolder"]
Drive -. "authenticated ciphertext only" .-> Sync
apps/
extension/ Primary product: WXT MV3 extension for Chromium and Firefox
web/ Companion React/Vite development and recovery surface
api/ Minimal Hono health worker; no vault keys or records
packages/
crypto/ Project-owned cryptographic interface
vault/ Key hierarchy, records, revisions, archives, sharing
security/ Autofill policy, generation, TOTP, password health
persistence/ IndexedDB repositories and compare-and-replace writes
sync/ Revision graph, clocks, merge, provider orchestration
provider-drive/ Google Drive provider adapter
provider-onedrive/ Experimental OneDrive adapter (not a v0.10 release path)
import-export/ CSV and Bitwarden-compatible import pipeline
ui/ Shared accessible React application shell
tooling/ Packaging, permission, CSP, secret, SBOM, and size gates
release/ Checksummed manifest, SBOM, and external release gates
VeyraKey generates random root and compartment keys, then wraps them for each authorized unlock method. Password rotation rewraps keys instead of decrypting and rewriting every record.
| Layer | Construction | Purpose |
|---|---|---|
| Master-password slot | Argon2id | Memory-hard derivation of a key-encryption key |
| Payload encryption | XChaCha20-Poly1305 | Confidentiality and authentication for records and archives |
| Domain separation | HKDF-SHA-256 | Separate keys by purpose and slot |
| Recovery Kit | 32 random bytes, Bech32m encoded | Offline recovery without server escrow |
| Device unlock | WebAuthn PRF when available | Locally authorized key unwrap |
Critical invariants are executable where possible and documented in
docs/26-security-invariants.md. The threat model and explicit
non-goals are in docs/03-trust-and-threat-model.md and
docs/17-constraints-and-non-goals.md.
- Node.js
24.11.0 - pnpm
11.10.0
CI=true pnpm install --frozen-lockfile
CI=true pnpm --dir apps/extension buildLoad apps/extension/.output/chrome-mv3 from chrome://extensions with Developer mode enabled.
After rebuilding or reloading the extension, refresh existing test pages so they receive the new
content script.
The toolbar popup is the main VeyraKey application. Pin the extension for quick access, create or restore a vault there, then test suggestions on HTTPS login and registration pages.
pnpm dev:webThe optional development/recovery UI opens at http://127.0.0.1:5173. It shares the vault UI and
core packages but is not required for normal extension use.
The application owner must register the extension OAuth client and enable the Drive API. End users then connect with a normal Google consent flow; they never enter a client ID.
- Create a Google Cloud OAuth client for the extension.
- Register the built extension ID and required redirect URI.
- Configure
VITE_GOOGLE_CLIENT_IDfor the build. - Grant only the Drive app-data scope used by the application.
OAuth consent, real-account restore, and account-switch tests remain external release gates because they require provider configuration and user interaction.
| Command | Purpose |
|---|---|
pnpm dev:extension |
Run the primary extension target in watch mode |
pnpm --dir apps/extension build |
Build Chrome and Firefox MV3 extension targets |
pnpm dev:web |
Run the optional development/recovery companion |
pnpm lint |
Biome formatting and lint rules |
pnpm typecheck |
Strict TypeScript across the workspace |
pnpm test |
Unit, property, integration, lifecycle, and compatibility tests |
pnpm build |
Production builds for packages and applications |
pnpm check |
Full automated release gate, including packaged extension verification |
pnpm release:verify |
Checks, checksummed manifest, and release-status evaluation |
The current release candidate passes:
- 259 tests across 38 test files.
- Strict TypeScript checks across 13 workspace packages.
- Web, Chrome MV3, and Firefox MV3 production builds.
- Extension packaging for Chrome, Firefox, and reviewable sources.
- Permission, CSP, source-map, embedded-secret, chunk-size, version-alignment, and SBOM checks.
The reproducible command is:
CI=true pnpm checkAutomated success is not the same as public-release approval. Physical biometric devices, live
Google OAuth, browser-store signing, and independent security/accessibility review are tracked in
docs/40-external-release-evidence.md.
Start with docs/README.md. Useful entry points:
- Product requirements
- System architecture
- Cryptography and key management
- BYOS sync protocol
- Browser extension architecture
- Testing and quality strategy
- Security invariants
- UX and accessibility
- Release runbook
- Implementation status
Read SECURITY.md before reporting a vulnerability. Never include real passwords,
Recovery Kits, OAuth tokens, or vault exports in an issue.
Built as an engineering portfolio project around explicit trust boundaries, reproducible evidence, and honest capability claims.