Password Manager
Phase 1 — Vault basics & crypto setup
- Create a single vault file
pwmanager.db(SQLite) with a single table:website,username,encrypted_password,created_at,updated_at. - Derive an encryption key from
<master_password>using a secure KDF with a stored random salt. - Encrypt/decrypt the password field using an authenticated cipher (e.g., AES-GCM or equivalent).
Functional result: First run creates the vault; adding one sample entry and reading it back (with the same master) returns the original plaintext password.
Phase 2 — CLI & core operations
- Parse:
pwmanager.py <master_password> -add <website> <username> <password>,-get <website>,-remove <website>,-list. -addinserts or updates the site entry;-getprints username + decrypted password;-removedeletes the site;-listprints website + username only.- Update
created_aton first insert andupdated_aton changes.
Functional result: Running the four sample commands creates an entry, retrieves it in plaintext, lists sites without passwords, and removes the entry exactly as specified.
Phase 3 — Master verification & data consistency
- On startup, verify the master password by attempting a controlled decryption (e.g., a canary/known record); abort if it fails.
- Enforce one entry per
website(unique constraint) so-addbehaves as upsert. - Keep timestamps consistent and store data as UTF-8.
Functional result: Supplying a wrong master cleanly stops any operation; re-adding an existing site updates its password and timestamp while preserving a single row per site.
Phase 4 — Light UX & Error handling
- Default vault location is the current directory; create it on first use.
- Display simple, readable console messages for each operation.
- Minimal error handling: show a concise usage hint on bad/missing args and a clear message on failed decryption (wrong master/corrupt entry).
Functional result: Typical mistakes (missing args or wrong master) produce short, clear messages without corrupting the vault; valid commands complete and persist correctly.