Vault is a tiny local password app with a simple rule: every master password is accepted. Vault can be used two ways. As a generator: any master you type is accepted and instantly shows a deterministic list of passwords you can use; type the same master later and you get the same list again, so you don’t have to save anything. As a vault: add your own passwords to that master and they’re stored locally in one encrypted file. You can use as many vaults as you want by using different masters. This “always‑accept” design provides plausible deniability: the app never rejects a master, so no one can tell if the opened vault is one you actually use or just another possible one.
This is a small open‑source experiment. It’s not meant to replace a standard, audited password manager
You can adjust defaults in encryption.py before running build.py (e.g., KDF iterations, generated password length/charset, list length). Keep values consistent across machines if you need compatibility.
pip install -r requirements.txt
python build.pyThe Windows executable is saved in the dist/ folder. You can move Vault.exe anywhere; when you add custom passwords, an encrypted vault file (passwords.enc) will be created in the same folder.
-
Start the app and type a master. Use Up/Down to scroll the list; press Ctrl+C to copy the current password.
-
Use the shown list as‑is, or add your own passwords to persist them in this vault. To add a new password, type it and press Enter.
-
Re‑enter the same master next time to access the same vault.
Notes:
-
No labels. You remember which item corresponds to which service.
-
No recovery. Forget the exact master for a saved vault or lose the vault file → data is unrecoverable.
-
No edit/delete. In‑place edit and delete are not implemented. Pressing Enter appends a new item if it’s unique.
-
File location & portability. The vault file (
passwords.enc) lives next to the executable by default. You can back it up or move it together with the app. -
Local‑only. No cloud, no telemetry.
Purpose: show the “always‑accept” concept; not a high‑security manager.
Applied measures:
- Local‑only operation.
- PBKDF2‑HMAC‑SHA256 with per‑vault salts for key derivation.
- Fernet (AES-CBC + HMAC) for encryption and tamper detection.
- Fixed pepper constant mixed into derivation, plus a light outer obfuscation.
Limitations:
- Not hardened against targeted attackers; obfuscation is cosmetic.
- Master secrecy is critical. If someone learns your master, they can open that vault. Use a strong random master (at least ~50 bits of entropy).
- Offline brute‑force is practical only for weak or patterned masters; with a ~50‑bit random master it’s computationally impractical at these KDF settings.
- Vault portability. Vaults are portable across machines if the app is built with the same internal constants and file format. There is no binding to specific hardware.
- Build vs data. If a future build intentionally changes internal secrets (pepper, etc.), old vaults may not open with that build. The current build does not do this, but the trade‑off is worth knowing if you modify internals.
- Deterministic list & Python versions. The generated list relies on Python’s RNG seeded from a per‑vault HMAC. Outputs can differ across Python versions.
🔲 Stable PRNG for deterministic list across Python versions.
🔲 Clipboard auto‑clear after N seconds.
🔲 Atomic writes and safer corruption handling.
🔲 Configurable charset/length for generated passwords.
🔲 Quality of life tray mode and a global hotkey to open the app quickly.
🔲 Optional build and/or hardware‑dependent mode (explicitly off by default).