◇ OpenCyber Academy
Engineering · Chapter 13 · English

Chapter 13 — Data systems

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Data systems

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Three tools for stored data"]
  N2["13.2 Storing passwords"]
  N3["13.3 Encryption at rest"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Three tools for stored data"]
  N2["13.2 Storing passwords"]
  N3["13.3 Encryption at rest"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Three tools for stored data]
    |
    v
[13.2 Storing passwords]
    |
    v
[13.3 Encryption at rest]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) choose between hashing, encrypting and tokenising stored data; (2) store passwords with memory-hard functions; (3) plan encryption at rest with separate keys.

13.1 Three tools for stored data

Ridgeway's database holds customer names, addresses, bank details and meter readings. Aiyana learns to choose the right tool for each field. Encryption hides data that must later be read, such as bank details for direct debit. Tokenisation replaces data with a meaningless reference stored elsewhere, useful when most systems need only a placeholder. Hashing, which is one-way, suits values that need only to be checked, never recovered. Picking the wrong tool, such as hashing bank details that must be used, or encrypting passwords that never need decrypting, creates either broken systems or unnecessary risk.

13.2 Storing passwords

Customer portal passwords must never be stored in plain text or with a fast hash such as SHA-256 alone, because attackers who steal the table can test billions of guesses per second. Aiyana recommends a memory-hard password hashing function, Argon2id from RFC 9106, which forces each guess to use significant memory and time, with a unique random salt per user. If Argon2 is unavailable, scrypt from RFC 7914 or PBKDF2 with a high iteration count are fallbacks. Python's hashlib offers scrypt and pbkdf2_hmac; production code still uses a vetted password-hashing library with sensible defaults.

13.3 Encryption at rest

For bank details, Ridgeway uses database encryption with a data-encryption key, itself encrypted by a key-encryption key held in the key service, a pattern called envelope encryption. Aiyana explains its benefit: rotating the key-encryption key requires re-encrypting only small data keys, not the whole database. She also notes a limit: encryption at rest protects against stolen disks and backups, but not against an attacker who queries the running application, which decrypts data for legitimate users. Access control and monitoring remain essential alongside encryption.

Worked example

Aiyana assigns encryption to bank details, tokens to reporting systems, and Argon2id with per-user salts to portal passwords, and designs envelope encryption with keys in the key service.

Synthetic case. The database is invented; RFC 9106 and RFC 7914 are real.

Errors and limits

Encryption at rest does not stop application-level theft. A slow password hash still fails if users choose very common passwords, so rate limiting and breach checks help.

Exercises

Synthesis

Matching hashing, encryption and tokenisation to each field, with memory-hard password hashing and envelope encryption, protects stored data proportionately.

Continue studying — chapter 13 of 50

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →