🌍 Python · flashcards
Python Password Manager Project Flashcards
50 question-and-answer cards covering Password Manager Project as it is examined in Python. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.
24 sample cards from the Password Manager Project deck
Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.
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.
What this deck covers
The Password Manager Project deck follows the Python Password Manager Project syllabus — 6 chapters and 11 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 8.3 cards per chapter.
Answers are written to be recallable, not just readable — averaging about 167 characters, which is long enough to carry the reasoning and short enough to say out loud.
A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.
Password Manager Project flashcards FAQ
How many Password Manager Project flashcards are in this Python deck?
50 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.
Are these Python flashcards free?
Yes. The preview here is free to read with no signup, and the full 50-card deck is free inside the Examius app.
What do the Password Manager Project cards cover?
They follow the Python Password Manager Project syllabus — 6 chapters and 11 topics — so the questions track what is actually examinable.
How should I use these flashcards?
Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.