Module 77: Encryption and Secrets

Why each option is right or wrong

• “Someone signed in to the running app and reading other users' records” (Incorrect): The running app decrypts data to use it, so misuse through the app is stopped by access control, not encryption at rest.
• “Bugs in the code that save the wrong values into the database” (Incorrect): Encryption stores whatever the code writes, right or wrong. Testing and review catch bugs.
• “Weak passwords that users choose for their own accounts” (Incorrect): Password strength is handled by sign-up rules and hashing, not by encrypting the disk.
• “Lost or stolen disks and backups being read” is correct.

  Encryption at rest scrambles data while it is stored, on disks, in database files and in backups. If a laptop is stolen, a backup is copied, or an old disk is thrown away, the data is unreadable without the key. It doesn't help when someone uses the running app, because the app decrypts data to work with it.

  • In transit: TLS protects data while it moves across networks.
  • Not a substitute: for access control, input checks or strong passwords.

📖 Revise: Lesson 1: Encryption in transit and at rest

Why each option is right or wrong

• “Symmetric only works offline, and asymmetric is used online” (Incorrect): Both work online and offline; the difference is how many keys there are.
• “Asymmetric uses no keys at all, only a shared password phrase” (Incorrect): Asymmetric encryption is built on a public and private key pair.
• “They're the same method, just with different key lengths” (Incorrect): Key length varies within each kind. The real difference is one shared key versus a pair.
• “Symmetric uses one shared key; asymmetric uses a key pair” is correct.

  Symmetric encryption, like AES, uses the same key to lock and unlock, so both sides must already share it safely. Asymmetric encryption uses a public key anyone can have and a private key only the owner keeps, which solves the problem of sharing a key with a stranger.

  • Speed: symmetric is much faster, so it handles the bulk data.
  • TLS uses both: asymmetric to agree a key, then symmetric for the traffic.

📖 Revise: Lesson 1: Encryption in transit and at rest

Why each option is right or wrong

• “Hashing can be reversed by the site if a user forgets” (Incorrect): Hashing is one-way by design. A forgotten password is reset, not recovered.
• “Encrypting stored passwords is against the law in most countries” (Incorrect): It isn't illegal; it's weaker, because the key can unlock every password.
• “Hashes take up less space than encrypted passwords do” (Incorrect): Size isn't the reason. The point is that a hash can't simply be turned back into the password.
• “They only need checking, so a stolen database doesn't reveal them” is correct.

  To sign someone in, you hash what they type and compare it with the stored hash. You don't need the original password back, so a one-way hash is safer: encrypted passwords can be decrypted by anyone who steals the key as well as the database.

  • Add a salt: a random value per user, so identical passwords give different hashes.
  • Reset, don't recover: a forgotten password is replaced, not shown.

📖 Revise: Lesson 2: Hashing vs encryption

Why each option is right or wrong

• “They're a form of encryption, so the key could be stolen” (Incorrect): SHA-256 is a hash with no key. The problem is its speed, not a key.
• “They're too slow, so users wait a long time to sign in” (Incorrect): The opposite: they're too fast, which helps attackers guess.
• “They can't hash text, only files and numbers” (Incorrect): They hash any data, including text. Speed is the weakness.
• “Attackers can try billions of guesses per second” is correct.

  SHA-256 is designed to be fast, which is great for checking files but bad for passwords. With a stolen hash, an attacker's graphics card can test billions of guesses a second. Password hashes like Argon2 and bcrypt are deliberately slow and memory-hungry, so each guess costs far more.

  • Use: Argon2id or bcrypt, through a well-known library.
  • Tune: a sign-in check taking a fraction of a second is fine for users.

📖 Revise: Lesson 2: Hashing vs encryption

Why each option is right or wrong

• “Keys stored on the same disk slow down reading and writing” (Incorrect): Speed isn't the concern. A leak of one place exposing both is.
• “Keys expire faster when they're stored beside the data” (Incorrect): Keys don't expire because of where they're stored; you rotate them on a schedule.
• “It makes the backups larger and slower to restore” (Incorrect): A key is tiny. The risk is that one backup holds everything an attacker needs.
• “Anyone who gets the data gets the key too” is correct.

  Encryption only helps if the key is harder to get than the data. If the key is in the same database, folder or backup, a single leak hands an attacker both, and the encryption achieves nothing.

  • Better: keep keys in a key management service or secrets store.
  • Limit access: few people and services should be able to use the key.

📖 Revise: Lesson 3: Keys

Why each option is right or wrong

• “Encrypting the content of emails before they're sent” (Incorrect): Email encryption is a separate topic. Envelope encryption is about wrapping data keys.
• “Putting sensitive files inside a password-protected zip folder” (Incorrect): A zip password is one key next to the data. Envelope encryption keeps the master key in a KMS.
• “Two separate passwords that must both be typed to open one file” (Incorrect): That's two-person control, not envelope encryption.
• “Data encrypted with a data key, which is encrypted by a master key in a KMS” is correct.

  Each piece of data is encrypted with its own data key. That data key is itself encrypted by a master key that stays inside a key management service (KMS). You store the encrypted data key with the data; to read it, you ask the KMS to unlock the data key.

  • Benefit: the master key doesn't leave the KMS.
  • Rotation: changing the master key means re-wrapping small data keys, not all the data.

📖 Revise: Lesson 3: Keys

Why each option is right or wrong

• “Yes, the deletion in the next commit removes it from the repository” (Incorrect): It's removed from the latest version only; the earlier commit still holds it.
• “Only if nobody cloned or pulled the repository today” (Incorrect): You can't know who copied it, and services or bots scan new commits within minutes.
• “Yes, as long as the repository is private” (Incorrect): Private repos still get shared, cloned and occasionally made public. Treat it as leaked.
• “No, it's still in history; change it immediately” is correct.

  Deleting a file in a new commit doesn't remove it from earlier commits. Anyone with a copy of the repository can look back and find it. Treat it as leaked: change the password first, then consider cleaning the history.

  • Order: rotate first, clean history second.
  • Prevent: keep secrets in .env and add a secret scanner.

📖 Revise: Lesson 4: Secrets

Why each option is right or wrong

• “Yes, if the code is obfuscated so the key is hard to spot” (Incorrect): Obfuscation hides it from a quick glance, but the browser still has to run it, so it can be found.
• “Yes, if the code is minified before it's deployed” (Incorrect): Minifying only shortens names and spacing; the key is still in the file.
• “Yes, if the site is served over HTTPS” (Incorrect): HTTPS protects the download in transit. Once it arrives, the visitor can read it.
• “No, anything sent to the browser can be read” is correct.

  Frontend code is downloaded to every visitor's browser, where they can open developer tools and read it. Tricks like minifying or obfuscating only slow people down. Secret keys belong on the server, which calls the other service for the browser.

  • Public keys: some services issue keys meant for browsers, limited by domain.
  • Pattern: browser calls your server; your server uses the secret.

📖 Revise: Lesson 4: Secrets

Why each option is right or wrong

• “Revoke the old one first, then create and install the new one” (Incorrect): That causes an outage between revoking and switching.
• “Create the new one and keep both active permanently” (Incorrect): Leaving the old secret active means a leaked copy still works.
• “Switch the app to a new value, then create that secret afterwards” (Incorrect): The app would use a secret that doesn't exist yet and fail.
• “Create new, switch the app, confirm, then revoke the old” is correct.

  Creating the new secret first means both are valid for a short time. You switch the app to the new one, check that it works, and only then revoke the old secret. Revoking first would break the app until the new one is in place.

  • Overlap: keep it short, minutes or hours.
  • After a leak: move faster and revoke as soon as the switch is confirmed.

📖 Revise: Lesson 5: Rotation

Why each option is right or wrong

• “They make sign-in faster because there's less to check” (Incorrect): They're about limiting damage, not speed.
• “They can be shared freely because they expire soon” (Incorrect): They should still be kept private; expiry only limits the harm of a leak.
• “They remove the need to protect secrets in logs” (Incorrect): Logs should still avoid credentials. Short life is an extra layer.
• “A leaked one is useful only briefly” is correct.

  Credentials that expire after minutes or hours limit the damage if they leak. An attacker who finds an old token in a log or screenshot usually finds it has already stopped working.

  • Examples: cloud role credentials, OAuth access tokens, signed URLs.
  • Paired with: automatic renewal, so users don't notice.

📖 Revise: Lesson 5: Rotation