Fund. of Information Security · Midterm

Ch.3 User Authentication → Ch.4 Access Control → Ch.5 Database Security

(s.N) = slide number of that chapter's deck.

User authentication = verifying an identity claimed by or for a system entity; basis of access control and accountability (s.4)

Two steps: identification (give identifier) + verification (bind person to identifier). Not message authentication (integrity of messages) (s.4)

Four means (s.5)

• knows: password, PIN
• possesses: key, token, smartcard
• is: fingerprint, retina (static)
• does: voice, signature (dynamic)

Use alone or combined; all have issues (s.5)

Five attacks: offline dictionary, specific account, popular password, single-user guessing, electronic monitoring (s.7)

Offline dictionary: steal the file, compare hashes with common ones. Fix: protect file, IDS, rapid reissue (s.8)

Specific account → lockout. Popular password (one password, many IDs) → ban common ones, scan IPs (s.9)

Single-user guessing → policy (length, charset, change time). Electronic monitoring → strong encryption (s.10)

Why a salt? hides duplicate passwords, slows offline dictionary attacks, hides reuse across systems (s.13)

UNIX Crypt(3): modified DES, password ≤ 8 chars = 56 bits, 12-bit salt, 11-char output; 'woefully insecure' (s.14)

↪ attacked by → 03 · Cracking & better passwords

Better schemes (s.15)

• MD5: 48-bit salt, 1000 loops, 128-bit hash; vulnerable
• Bcrypt (Blowfish): 128-bit salt, 192-bit hash; most secure

Verify: user id picks row → stored salt + typed password → crypt(3) → compare with stored hash (s.12)

Rainbow table = precomputed hashes for all salts: 1.4 GB cracks 99.9% of alphanumeric Windows passwords in 13.8 s; fails with larger salts (s.16)

Purdue: 3% of 7000 passwords ≤ 3 chars; 14,000 hashed: ~1/4 guessed; 25,000 students: >10% after $10^{10}$ guesses (s.17-18)

Shadow file: hashes in a separate, privileged-only file. Still leaks via OS bugs, bad permissions, backups, sniffing (s.19)

Reactive checking: system cracks own file, costly. Proactive: reject weak choice when set; likely best (s.20)

Token = object the user possesses (s.21)

Memory card: stores only, magnetic stripe; needs reader, can be lost; fine for ATM, not for computers (s.22)

Smartcard: own processor, memory, I/O (s.23)

• static (like memory card)
• dynamic (new password every minute)
• challenge-response (hash of random number)

Biometrics: face, fingerprint, hand, retina, iris, signature, voice. Iris = highest cost and accuracy (s.24)

Matching score vs stored template; noise → errors. False match = imposter accepted; false non-match = genuine rejected; threshold $t$ trades them (s.25)

Iris banking system (s.32): PIN or iris (high-value); verification server: decrypt → reconstruct → encode → match against iris DB + CIN

Challenge-response: user sends ID → host sends random $r$ → user returns $f(r, h(P))$ → host compares (s.26-27)

↪ used by → 03 · Tokens

Client attack → strong passwords, limit attempts. Host attack → hashing, protect DB (s.28-29)

Eavesdropping → diligence, multifactor, revoke. Replay → challenge-response, OTP (s.30-31)

Exam traps (quiz style: one-word fill-in, see Past Exam note)

Q: Hashes kept in a separate file? A: shadow file (s.19)

Q: Random value added before hashing? A: salt; it is stored in clear next to the hash (s.12-13)

Q: Attacker re-sends a captured response? A: replay → challenge-response / OTP (s.31)

Q: False match vs false non-match? A: imposter in vs genuine out (s.25)

Gap: slides name Bloom filters (s.3) and an ATM case study (s.2) but never explain them

Access control = prevention of unauthorized use of a resource, including use in an unauthorized manner; central to computer security (s.2)

Flow: user → authentication → access control function (checks authorization database) → resources; auditing watches all (s.3)

A policy in the authorization database says what access, under what circumstances, by whom (s.4)

Three policies (s.4-6) - may combine all three

• DAC: identity + rules; holder can pass access on
• MAC: labels vs clearances; holder cannot
• RBAC: roles

DAC = traditional; owner decides ('discretionary') (s.4, 6)

MAC: TOP SECRET, SECRET, CONFIDENTIAL, UNCLASSIFIED; military origin, trusted systems (s.5-6)

RBAC: rights to roles, not users; increasingly popular (s.6, 21)

↪ detail → 04 · RBAC

Requirements (s.8-9) reliable input · fine/coarse grain · least privilege (minimum needed) · administrative policies

Closed policy: only what is authorized (most used). Open policy: all except prohibited (s.9)

Elements (s.10-11)

• subject: owner, group, world
• object: files, records, programs
• right: read, write, execute, delete, create, search

↪ used in → 04 · Access matrix

Access matrix: rows subjects, columns objects, entries rights; sparse. Rows → capability lists, columns → ACLs (s.12-13)

Extended matrix: objects include subjects (control, owner), processes (wakeup, stop), disks (seek, owner); * = copy flag (s.14-16)

Transfer if $A[S,X]=r^*$, or owner, or ($r$ and control over S'). Delete if owner or control (s.17)

Check $(S_0,\alpha,X)$: allowed iff $\alpha \in A[S_0,X]$, else protection violation (s.18)

RBAC vs DAC: rights go to roles; users get roles by responsibility; user-role is many-to-many (s.21)

Models (s.24)

• RBAC0 base
• RBAC1 + role hierarchies
• RBAC2 + constraints
• RBAC3 = both

RBAC0 entities: user, role, permission (= right, privilege, authorization), session (s.25)

RBAC1: inheritance; Director > Project Lead > Production/Quality Engineer > Engineer > Engineering Dept. (s.26)

RBAC2 constraints (s.27)

• mutual exclusion: one role of the set
• cardinality: max users per role
• prerequisite: must hold another role first

Exam traps (see Past Exam note: one-word terms)

Q: Minimum permissions to do the job? A: least privilege (s.8)

Q: DAC vs MAC? A: DAC lets the holder pass access on; MAC does not, labels vs clearances (s.4-5)

Slide error: capability list for User A shows File 2 Read, but the matrix gives A File 3 (s.13)

Class notes only: rule-based AC and Active Directory are not on the slides (Added Context)

Relational DB: tables of rows and columns, linked by a unique identifier (s.4-5)

Terms (s.7) relation = table = file; tuple = row = record; attribute = column = field primary key uniquely identifies a row; foreign key links tables; view = virtual table from a query

SQL: IBM, mid-1970s; defines, manipulates, queries data; CREATE TABLE / FOREIGN KEY / CREATE VIEW (s.10)

SQLi: malicious SQL to the DB server → modify/delete data, run OS commands, DoS (s.11)

Tautology: password name' OR 'a'='a makes WHERE always true → SELECT * FROM items, all rows (s.13-14)

↪ category → 05 · SQLi categories & defences

Piggyback + comment: John'; DROP table Course;-- ends the string, adds a command, -- comments the rest (s.15)

Categories (s.16)

• In-band: same channel (tautology, --, piggyback)
• Inferential: no data shown; behaviour/timing (blind)
• Out-of-band: other channel (DNS/HTTP, email)

Inferential: illegal/logically incorrect queries reveal DB structure through descriptive error pages (s.18)

Defences (s.20)

• defensive coding: validate input (numeric = digits only)
• detection: signature, anomaly, code analysis
• runtime prevention: match expected queries

Administration (s.21)

• centralized: few privileged users
• ownership-based: table owner
• decentralized: owner can delegate granting

↪ bypassed by → 05 · Inference

GRANT {privs|role} [ON table] TO {user|role|PUBLIC} [IDENTIFIED BY pw] [WITH GRANT OPTION]; REVOKE ... FROM ...; e.g. GRANT SELECT ON ANY TABLE TO john (s.22)

Rights: SELECT, INSERT, UPDATE, DELETE. PUBLIC = any user; GRANT OPTION = grantee can pass it on (s.22-24)

Inference = authorized queries + deduction → unauthorized information (s.25)

Techniques: functional dependencies (Rank → Salary); merging views (s.26)

Views example: V1 (Availability, Cost) + V2 (Item, Department), same row order → Item-Cost link revealed (s.27-28)

Fix: at design (split table, finer RBAC roles) or at query time (deny/alter) (s.29)

Encrypt: entire DB = inflexible; rows or columns = best, plus attribute indexes (s.30)

Range queries fail: encrypted values lose ordering, e.g. Salary > 7000 (s.33)

Fix: encrypt each row as a block $E(k,B)$ + index per attribute (Eid 1-200 → 1 ... 801-1000 → 5) (s.34-35)

eid < 300 → request $I(eid) \le 2$ → decrypt rows → discard non-matches → plaintext to user (s.36)

Exam traps (see Past Exam note)

Q: Injected always-true condition? A: tautology (s.17)

Q: Inferential SQLi vs inference? A: attack category (blind) vs leak via authorized queries (s.16, 25)

Q: Why can't an encrypted salary column do range queries? A: ordering not preserved (s.33)

Gap: s.38 lists statistical database security, no slide covers it