Python Password Manager Project Syllabus

Write the two-line Python pattern to encrypt a plaintext password string into a Fernet token.

``` token = cipher.encrypt(password.encode()) # token is bytes; store in the database ```

What does a Fernet token contain besides the ciphertext?

A version byte, a timestamp (when the token was created), the 16-byte IV, the AES-CBC ciphertext, and a 32-byte HMAC signature — all base64url-encoded together.

Why must a string be encoded with `.encode()` before passing it to `Fernet.encrypt()`?

Because `Fernet.encrypt()` operates on `bytes`, not `str`. `.encode()` converts the string to UTF-8 bytes; passing a `str` raises a `TypeError`.

Which Fernet method decrypts a token, and what does it return?

`cipher.decrypt(token)` returns the original plaintext as `bytes`. Call `.decode()` to convert it back to a string.

Write the Python pattern to decrypt a stored Fernet token back into a readable password string.

``` plaintext = cipher.decrypt(token).decode() ```

What exception does Fernet raise when a token is invalid, tampered with, or decrypted with the wrong key?

`cryptography.fernet.InvalidToken`. It is raised when the HMAC verification fails or the token is malformed, which protects against tampering and wrong-key use.

How does Fernet guarantee that decrypted data has not been tampered with?

It verifies the HMAC-SHA256 signature before decrypting. If the signature does not match the ciphertext, it raises `InvalidToken` and never returns altered plaintext — providing authenticated encryption.

What is the relationship between the key used to encrypt and the key used to decrypt in Fernet?

They must be identical. Fernet is symmetric, so the exact same key that encrypted a token is required to decrypt it; any other key raises `InvalidToken`.

What does a command-line interface (CLI) provide as the user-facing layer of the password manager?

A text-based interface where the user runs commands (add, get, list, delete) with arguments in the terminal to manage stored credentials without a GUI.

Which standard-library module is recommended for parsing CLI arguments, and what is its main class?

The `argparse` module. Its main class is `argparse.ArgumentParser`, which defines arguments/subcommands and produces a parsed namespace via `parser.parse_args()`.

How do you set up multiple commands like `add`, `get`, and `list` using argparse?

Use subparsers: `subparsers = parser.add_subparsers(dest='command')`, then `subparsers.add_parser('add')`, etc. Each subparser can define its own arguments.

Why should the master password or key be read using `getpass.getpass()` rather than `input()` in the CLI?

`getpass.getpass()` reads input without echoing it to the terminal, preventing the master password from being displayed on screen or captured in shell history.

In the CLI, what is the typical flow when a user runs the `add` command?

Read the service, username, and password; encrypt the password with Fernet; insert the service, username, and encrypted token into the SQLite table; then commit the transaction.

In the CLI, what is the typical flow when a user runs the `get` command for a service?

Query the database for the row matching the service; retrieve the encrypted token; decrypt it with the Fernet cipher; then display the username and decrypted password.

What is a round-trip test for encryption and decryption?

A test that encrypts a known plaintext and then decrypts the resulting token, asserting that the decrypted output equals the original plaintext: `decrypt(encrypt(p)) == p`.

Write an assertion that verifies Fernet encryption/decryption round-trips correctly for the password "S3cret!".

``` assert cipher.decrypt(cipher.encrypt(b"S3cret!")) == b"S3cret!" ```

When testing encryption, why should you assert that the ciphertext is NOT equal to the plaintext?

To confirm the data was actually transformed (encrypted) rather than stored in plain form: `assert token != b"S3cret!"` guards against an accidental no-op encryption.

How do you write a test asserting that decrypting with a wrong key raises an error?

Use `pytest.raises(InvalidToken)`: encrypt with one key, then call `Fernet(other_key).decrypt(token)` inside the context manager and assert that `InvalidToken` is raised.

Why is it useful to encrypt the same plaintext twice and observe that the tokens differ?

Fernet includes a random 16-byte IV and a timestamp, so encrypting identical plaintext yields different tokens each time. This non-determinism prevents attackers from detecting repeated passwords.

What is the advantage of using an in-memory SQLite database (`sqlite3.connect(':memory:')`) in tests?

It is fast, requires no file cleanup, and gives each test an isolated, fresh database that disappears when the connection closes — avoiding interference between tests.

Describe a basic test for the database insert-and-retrieve operation.

Insert a known row (service, username, encrypted password), query it back by service, and assert the returned values match what was inserted — verifying the storage layer works end to end.

Why should each database test start with a freshly initialized schema?

To ensure test isolation and repeatability: a fresh schema (e.g., in-memory DB or setup fixture) prevents leftover data from previous tests causing false passes or failures.

What pytest fixture pattern is commonly used to provide a clean database connection to each test?

A fixture decorated with `@pytest.fixture` that creates an in-memory connection, initializes the schema, `yield`s the connection to the test, and closes it afterward for teardown.

What does "secure storage" mean in the context of this password manager?

Passwords are never written to disk in plaintext — only encrypted Fernet tokens are stored in the database, and the encryption key is kept separate from that database.

Why should the encryption key NOT be stored in the same SQLite database as the encrypted passwords?

Because anyone who obtains the database file would then have both the ciphertext and the key, defeating the encryption. The key must be stored separately (e.g., a protected key file, environment variable, or OS keyring).

How can `python-dotenv` and a `.env` file contribute to secure storage of the key?

The key (or its path) is placed in a `.env` file loaded at runtime via `load_dotenv()`, keeping it out of source code. The `.env` file is added to `.gitignore` so it is never committed.

Why must files like `.env`, the key file, and `*.db` be added to `.gitignore`?

To prevent accidentally committing secrets and personal password data to version control, where they could be exposed publicly or in the repository history.

What file permission practice helps protect a key file on a Unix system?

Restrict it to owner-only read/write with `chmod 600 keyfile` (octal $600$), so other users on the system cannot read the encryption key.

What two essential pieces of information should the project README/documentation explain for a new user?

How to install dependencies and set up the key (installation/setup), and how to use each CLI command (add, get, list, delete) — typically with example commands.

Why is documenting the key backup and recovery procedure critical for a password manager?

Because losing the encryption key makes all stored passwords permanently unrecoverable. The docs must warn users to back up the key safely, since there is no reset or recovery path.