CredStore is a strictly offline personal credential manager for desktop, web, and Android.

Install

npm

npm install -g credstore

On Linux, the desktop launcher is installed automatically during package installation when npm allows install scripts. If install scripts are blocked, credstore still launches by caching Electron in the current user's cache directory. Use credstore -version to print the installed version and credstore -debug to launch with debug logging and developer tools enabled.

CredStore clears old local desktop vault/authentication state during package installation so a fresh npm install starts from a clean local state on Linux, macOS, and Windows.

To remove the global npm launcher:

npm uninstall -g credstore

Current npm versions do not reliably run package uninstall lifecycle scripts, so npm uninstall cannot be the only cleanup guarantee. CredStore therefore clears stale desktop vault/authentication state automatically on the next install. Windows NSIS builds also request app-data deletion during uninstall. Android clears its app sandbox on uninstall and has a restored-data guard on reinstall. iOS clears retained biometric keychain entries on first launch after reinstall.

GitHub

npm install -g github.com:LocaMartin/credstore

Windows

winget install credstore

winget install credstore will not work until CredStore is accepted into the official winget package index.

Android

GitHub Releases include Android APK/AAB artifacts from the release workflow. The Uptodown listing can be used when published:

https://credstore.en.uptodown.com/android

Features

• Strictly offline credential storage.
• AES-256-GCM encrypted vault data.
• PBKDF2-SHA-256 key derivation with 600,000 iterations and 24-byte salts.
• Encrypted vault keys wrapped by one or more password master keys.
• Native Android/iOS biometric keychain support for OS-reported fingerprint, Touch ID, Face ID, or Android face unlock.
• Flexible credential fields: store usernames, passwords, API secrets, URLs, tokens, notes, or any custom key/value.
• Per-field secret masking and copy controls.
• Credential notes are shown on saved credential cards.
• Website, API, database, and other categories.
• Search and category filtering.
• Post-login settings with multiple themes and master-key management.
• Offline Sync button with client/receiver modes, short QR/OTP pairing, Android/iOS Bluetooth transfer, and desktop local Wi-Fi/LAN transfer.
• Community sync for up to 5 devices, with signed offline enterprise licenses for larger teams.
• Employee profile and role metadata foundation for enterprise visibility controls.
• Android edge-to-edge layout and frameless Electron desktop windows to remove black bezel/titlebar space.
• Android FLAG_SECURE, disabled app backup, no Internet permission, and hardcoded credstore deep-link scheme.
• Electron network request blocking, permission denial, renderer sandboxing, and content protection.
• Restrictive Content Security Policy with connect-src 'none'.

Master Keys

CredStore supports multiple master keys. Each password master key wraps the same random vault key, so any enabled password key can unlock the vault without storing plaintext credentials or a reusable password verifier.

Password master keys must be at least 8 characters and include lowercase, uppercase, number, and symbol characters. After 10 failed unlock attempts, CredStore applies a local lockout delay.

Fingerprint and face recognition keys are available only through tested platform-native bridges:

• Android and iOS use native biometric/keychain support through Capacitor plugins.
• macOS uses Touch ID when Electron can call the local system biometric prompt.
• Windows Hello and Linux fingerprint unlock are disabled until CredStore has tested native key-release bridges for those platforms.

When native biometric support is unavailable, CredStore falls back to password master keys.

Security Architecture

CredStore treats every offline client device as a hostile environment. No offline-only app can fully stop a determined attacker with local admin access, but CredStore layers controls so bypassing one check does not expose plaintext vault data or automatically unlock premium features.

CredStore does not rely on hiding user secrets inside the app binary. If someone decompiles the app with Ghidra, IDA Pro, apktool, or strings, user credentials still depend on:

• The user's master key strength.
• Random salts and IVs.
• PBKDF2-SHA-256 key stretching.
• AES-256-GCM authenticated encryption.
• No stored plaintext master key.
• No stored reusable login verifier.

Offline brute force cannot be made impossible if an attacker has the encrypted vault and the user chose a weak master key. Use a long, unique master key.

Offline Hardening Layers

• Vault cryptography: AES-256-GCM authenticated encryption, PBKDF2-SHA-256 with 600,000 iterations, random 24-byte salts, random IVs, and a random vault key wrapped by each master key slot.
• Biometric key release: biometric slots store only protected vault-key material. The biometric prompt must succeed before the native bridge returns the wrapped secret to the renderer.
• Offline license validation: enterprise tokens use Ed25519 signatures. The app contains only the verification public key, split into fragments, and validates account identity, expiry, device/user limits, and feature flags locally.
• Clock rollback guard: signed trial and enterprise license validation records the last seen time locally and rejects obvious system-clock rollback attempts.
• Electron file integrity: packaged desktop builds verify a generated SHA-256 manifest for exported app assets and Electron entry files before opening the vault UI.
• Android app signature pinning: release builds can set EXPECTED_ANDROID_CERT_SHA256 so the app verifies its signing certificate hash at startup and exits if it was re-signed.
• Runtime protection: release builds check common debugger, tracing, root, jailbreak, Frida/Xposed, and remote-debugging indicators where the platform exposes reliable local signals.
• OS code signing: production Windows, macOS/iOS, and Android releases should still be signed with the platform-native certificate systems. The in-app checks are a second layer, not a replacement for OS-enforced signing.

For Android production builds, set the expected certificate fingerprint before building:

EXPECTED_ANDROID_CERT_SHA256=AA:BB:CC:... ./gradlew assembleRelease

Strict Offline Controls

• The web app uses a CSP with connect-src 'none'.
• Electron blocks non-local network requests at the session level.
• Electron production file loading is restricted to the exported app directory.
• Android removes the Internet permission from the merged manifest.
• Android cleartext traffic is disabled.
• The app uses a hardcoded credstore deep-link scheme.

Development builds may use localhost for Next.js and Electron dev mode.

Dual-Licensing & Why Sponsor CredStore?

CredStore is fundamentally built on a zero-knowledge, client-side open-source architecture. The public repository is licensed under AGPLv3-or-later because transparency and reciprocal source availability matter for security tools.

However, building cross-platform environments, maintaining native security wrappers like Android Keystore and Electron sandbox isolation, and hosting packages on official storefronts incurs real-world platform fees.

We balance this using a dual-license open-core model based on convenience and scale. Public repository code is governed by the root LICENSE; closed-source Pro and Enterprise code is governed by LICENSE-PRO.md.

1. Frictionless Distribution vs. Manual Compilation

• The Free Path: You can freely clone this repository, install dependencies via Node.js, compile your own Electron desktop binaries, use the local terminal engine, or sign an Android APK/AAB target with your own developer keys.
• The Paid Path: When you purchase CredStore on the official app stores, you are paying for frictionless convenience. You receive a signed, code-verified, sandboxed, and auto-updating application with a single click. Your app store purchase directly funds ongoing developer ecosystem fees.

2. Community vs. Enterprise & Team Edition

To accommodate normal personal use while funding large-scale operational tools, the software enforces scale boundaries locally:

• Community Edition (Free): Completely free local vault management and secure local device synchronization for up to 5 devices using short QR/OTP pairing plus encrypted local transport.
• Enterprise Edition (Paid): Designed for businesses and collaborative privacy teams requiring structured profile management, employee/admin access metadata controls, and synchronization across larger hardware fleets.

3. Local License Verification (Privacy First)

True to the strictly offline app design policy, license token validation happens locally using asymmetric public-key cryptography. The application reads a signed offline token; it never speaks to a license activation server or exposes your footprint to the internet.

License generation happens outside the app:

• GitHub Pages source: web/
• Cloudflare Worker signer: managed in the Cloudflare Dashboard, not committed to this repository.
• Commercial/proprietary source area: pro
• Commercial license terms: LICENSE-PRO.md

The static website must never contain the private signing key. The Cloudflare Worker signs tokens with LICENSE_PRIVATE_JWK stored as a Worker secret. The app ships only the public verification key.

The Worker should read secrets and variables from Cloudflare, not source files:

• LICENSE_PRIVATE_JWK: Worker secret containing the private signing key.
• ALLOW_UNPAID_LIFETIME: Worker variable for manual/testing behavior.
• TEST_KEY_SECRET: optional Worker secret for internal test-license issuance.
• CONTACT_WEBHOOK_URL: optional Worker secret for contact form delivery.

Paid licenses can be bound to the account identity shown in CredStore Settings. A copied license token or QR screenshot will be rejected by a different vault if the signed accountIdentity does not match.

Offline anti-piracy cannot completely stop someone from copying a license token or photographing a QR code. CredStore can reduce abuse with signed tokens, buyer/company metadata, local device limits, screenshot protection where supported by the OS, and commercial terms. It cannot provide server-style activation enforcement without becoming an online app.

Supporting the Mission

If CredStore secures your personal data infrastructure, consider fueling its development:

• Sponsor the Project: Support via GitHub Sponsors or Open Collective to help execute roadmap items like local Bluetooth/Wi-Fi transport channels.
• Corporate Backing: Privacy-focused organizations and security firms can secure premium visibility slots on repository documentation by choosing a corporate sponsorship tier.

Encryption Process

1. User enters a master key.
2. PBKDF2 derives a key from the master key and random salt.
3. That derived key unwraps the random vault key.
4. The vault key decrypts the AES-256-GCM vault payload.
5. Failed unlock attempts apply local exponential backoff.
6. New vault writes re-encrypt credential data locally only.

Reset

If you forget every master key, the vault cannot be recovered. There are no recovery keys, backdoors, or server copies.

After login, open Settings and use Reset in the danger zone to delete local vault data and start fresh. Reset removes current vault storage, legacy storage, and failed-unlock lockout state:

localStorage.removeItem("credstore_vault_v2");
localStorage.removeItem("credstore_data");
localStorage.removeItem("credstore_lockout_until");
location.reload();

On Android, reset also clears Capacitor Preferences through the app UI. Android backup/device-transfer rules and the Windows NSIS uninstaller are configured to erase app data on uninstall, so reinstalling starts from a clean vault state.

Tests

npm run test:security
npm run lint
npx tsc --noEmit
npm run build
npm run android:sync

For Android native packaging, use JDK 21:

cd android
JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64 ./gradlew assembleDebug assembleRelease

Distribution

• GitHub Releases: desktop installers and Android release files.
• npm: CLI and Electron launcher.
• winget: Windows package distribution.
• Uptodown: Android listing when published.

Contributing

1. Fork the repository.
2. Create a feature branch: git checkout -b feature/amazing-feature.
3. Commit your changes: git commit -m "Add amazing feature".
4. Push to the branch: git push origin feature/amazing-feature.
5. Open a Pull Request.