Notes on Chapter 2-3: Authentication, Access Control, and Cryptography

2.1 Authentication

  • Security toolkit concept: Authentication, Access Control, and Cryptography are the three foundational tools.
  • Authentication is the process of confirming an asserted identity; it answers: “Are you really who you claim to be?”
  • Policy and enforcement: A security policy states who (subjects) can access what (objects) and how; enforcement must reliably determine identity to prevent impersonation.
  • Core ideas:
    • Identification vs. Authentication
    • Identification: asserting who you are.
    • Authentication: proving that the asserted identity is correct.
    • Subjects and objects: subjects are users, processes, devices; objects are resources (files, memory, devices, networks).
    • Authentication is necessary for access control to work; without strong authentication, policy enforcement is ineffective.
  • The three bases of authentication (something you know, something you are, something you have) can be combined to strengthen security.
  • Why authentication matters: attackers want something defenders have; authentication helps prove who is who, enabling proper access control.
  • Sidebar context: Historical analogies (watchwords/passwords) illustrate the ongoing need to prove identity, not just claim it.
  • Practical takeaway: Authentication mechanisms must balance strength, usability, and cost; strong authentication often uses multiple factors.
  • Example framing: In real systems, authentication feeds into policy enforcement that decides access rights and modes; weaknesses in authentication undermine the whole security policy.
  • Notable caution: Public identifiers can be easy to impersonate; authentication must be private and resistant to impersonation.
  • Threats regarding identity management include political/historic examples of compromised identities (e.g., high-profile email breaches) to illustrate the importance of robust authentication.

2.1.1 Something You Know: Passwords, PINs, Passphrases

  • Authentication parameter: something you know (passwords, PINs, passphrases).
  • Password usage basics: user provides an ID, system asks for a password; match grants access; mismatch prompts retry.
  • Password weaknesses and usability problems:
    • Use and disclosure: improper handling leads to compromises; password changes require relay of new credentials to legitimate users.
    • Revocation and loss: changing passwords to revoke access can disrupt legitimate users; forgotten passwords require reset.
    • Common user behavior leads to weak passwords (e.g., “qwerty”, “password”, “123456”).
    • Dictionary and brute force attacks: attackers try common words and then expand to larger word/morphological spaces; speed of attacks grows with computing power.
  • Dictionary attacks and brute force: attackers leverage dictionaries, common phrases, and substitutions (e.g., 0 for O, 1 for I) to guess passwords; full brute force scales with password length and character set.
  • Rainbow tables: precomputed hashed values for common passwords, enabling rapid offline cracking if the password hash is obtained; effectiveness is reduced by salting.
  • Salts: per-user random data added to the password before hashing; makes identical passwords produce different hashes and defeats rainbow tables.
  • Password storage and concealment: operating systems store a one-way “concealment” (hash) of a password; even if the hash table is stolen, reversing to the original password is designed to be infeasible.
  • Password cryptography basics:
    • One-way transformation: concealment is easy to compute from password, but hard to invert.
    • If a password is forgotten, systems can reset to a new random password rather than reveal the old one.
  • Usability challenges (Usability in the Small vs. Usability in the Large):
    • Managing many passwords is hard; password managers can help by storing credentials securely behind a single master password.
    • Multi-factor considerations: increasing factors can improve security but may also reduce usability; careful balancing is required.
  • Security phenomena and historical notes:
    • Thucydides’ watchword example illustrates early password-management problems (secret vs. public identifiers).
    • Early studies (Morris & Thompson; Klein; Spafford; Egg bank) show long-standing weaknesses in password selection and the rapid evolution of attacker capabilities.
  • Password selection guidance from the chapter:
    • Use long, non-dictionary, non-obvious phrases; avoid actual names or words; consider derivations from memorable phrases that are not easily guessable.
    • Use variants and context-specific modifications to avoid single-point weaknesses across multiple accounts.
    • Change passwords periodically; don’t reuse across critical accounts; avoid simple patterns.
    • Protect passwords: don’t share; beware of social engineering; beware of shoulder-surfing and peering.
    • Consider a password manager to handle multiple credentials securely.
  • Social-engineering and security questions:
    • Social media often exposes easily guessable security question answers (e.g., mother’s maiden name, childhood street, first pet).
    • Security questions as authenticators are weak; attackers can gather public data to answer them.
  • Password-related sidebars and examples:
    • Sidebar 2-1: Public figures’ emails hacked via impersonation (password reset via security questions/identities).
    • Sidebar 2-2: Facebook security questions and data leakage; advises using non-public answers or malleable answers.
    • Sidebar 2-3: An old problem with passwords; Thucydides’ password/watchword example.
    • Sidebar 2-4: Usability in password management; recovery phrases (e.g., 12–24 word phrases) as a cognitive burden.
  • Password use in practice:
    • Typical login flow involves user ID and password; if correct, authentication succeeds and access is granted; incorrect input prompts retry.
    • Watch for the practical need to adapt authentication to user workflows and system requirements.
  • Password-handling mechanisms in OSes:
    • Passwords stored as concealed hashes; direct password retrieval is not possible; resets are common when forgotten.

2.1.2 Something You Are: Biometrics

  • Biometric authentication uses inherent physical or behavioral traits (e.g., fingerprint, voice, face, iris, handwriting, gait).
  • Advantages: cannot be lost, forgotten, stolen, or shared; always available; difficult to replicate perfectly.
  • Core concept: biometric systems use a template (baseline) and compare a current sample to the template; success requires a close enough match, not a perfect one.
  • Dichotomous decision process: match or no match; evaluation includes true positives, false positives, true negatives, false negatives (TP, FP, TN, FN).
  • Performance measures:
    • Sensitivity (true positive rate): ext{Sensitivity} = rac{TP}{TP+FN}
    • Specificity (true negative rate): ext{Specificity} = rac{TN}{FP+TN}
    • Prevalence: ext{Prev} = rac{TP+FN}{TP+FP+FN+TN}
    • Accuracy: ext{Accuracy} = rac{TP+TN}{TP+FP+FN+TN}
    • Positive Predictive Value (PPV): ext{PPV} = rac{TP}{TP+FP}
    • Negative Predictive Value (NPV): ext{NPV} = rac{TN}{TN+FN}
    • ROC curves: trade-off between false positives and false negatives; FPR = 1 − Specificity; TPR = Sensitivity; Area Under Curve (AUC) measures overall performance (AUC = 1 is perfect, AUC = 0.5 is worthless).
  • Enrollment vs. matching: biometrics are reliable for authentication but less reliable for identification (e.g., recognizing who someone is from a large set).
  • Common biometric authenticators:
    • Fingerprint, voice, face recognition; mobile devices increasingly include these capabilities.
  • Issues and challenges:
    • Enrollment issues, environmental factors (lighting, noise, glasses), and sample quality affect accuracy.
    • Forgeries and spoofing (e.g., fake fingerprints, tinted contact lenses to fool iris recognition) exist; attackers may attempt to spoof sensors.
    • Masterprints and partial prints can reduce security in practice; spoofing may succeed under marginal conditions.
    • Biometric systems can be intrusive and raise privacy concerns; different stakeholders weigh risks differently (e.g., government adoption, corporate use).
  • Accuracy and fairness concerns:
    • Enrollment and algorithm biases can cause disparate false positives/negatives across demographics (ethnicity, age, gender, eyewear).
    • Sidebars and case studies discuss government restrictions on facial recognition due to bias and privacy concerns; real-world evaluations (NIST, IBM) show uneven performance across groups.
  • Biometric usability notes:
    • Biometrics can be fast and convenient but may suffer from device-specific and environmental limitations; combining multiple biometrics can improve accuracy (e.g., image + voice).
  • Practical considerations:
    • Biometrics are not perfect; there is always a trade-off between false positives and false negatives, and the system is constrained by speed/throughput needs.
  • Sidebar references:
    • Sidebar 2-7: U.S. government’s stance on facial recognition use and privacy concerns.
    • Sidebar 2-8: Biometric forgery examples (gummy fingers, iris-lens tricks).
    • Sidebar 2-9–2-11: DNA as identifier vs. authentication; fingerprint examiners’ error rates; evaluation challenges; and the need to report validation statistics.

2.1.3 Something You Have: Tokens

  • Token-based authentication uses a physical object to prove identity (e.g., keys, badges, smart cards, phones with credentials).
  • Token properties:
    • Static tokens: value does not change (e.g., key, photo ID, magnetic stripe card, RFID badge).
    • Dynamic tokens: value changes over time or per action (e.g., one-time passcodes, SecurID);
    • Dynamic tokens resist replay; values are valid for a short window or a single session.
  • Static vs. dynamic tokens:
    • Static tokens are vulnerable to skimming and cloning; dynamic tokens mitigate replay risks.
    • Skimming: copying authentication data by intercepting token data (magnetic stripe, RFID, or card data) and reproducing it elsewhere.
    • Dynamic tokens generate unpredictable values that make replay unusable for future sessions.
  • Skimming risks across payment and access control systems; chip-based (EMV) cards reduce skimming risks relative to magnetic stripes in many regions, but older or legacy systems may still be vulnerable.
  • Token types and communication modes:
    • Passive tokens: do not change (e.g., photo ID); used for onsite verification.
    • Active tokens: involve a change in state or interaction with a reader (e.g., magnetic stripe reader updating balance).
    • Static vs. dynamic interaction: static tokens are fixed; dynamic tokens involve ongoing interaction with a reader or a network.
  • Remote authentication challenges with tokens:
    • Transported tokens used for remote authentication may introduce new attack surfaces; attackers may attempt to substitute or relay token data.
  • Specific token examples:
    • Key cards and physical badges used for building access; passports; credit cards with magnetic stripes; RFID devices; OTP generators (e.g., RSA SecurID, challenge-response tokens).
  • Authentication design patterns:
    • Federated Identity Management: a union of separate identity/authentication systems to simplify cross-system access.
    • Single Sign-On (SSO): one umbrella authentication that enables access to multiple independent systems; reduces repeated logins but relies on a central trusted identity source.
  • Multifactor authentication (MFA): combining two or more factors (e.g., knowledge + possession, or possession + biometrics) to improve security; trade-offs include usability and risk of factor compromise.
  • Practical MFA examples:
    • Banks often implement MFA by requiring ID/password (knowledge) and a one-time code sent to a phone or email (something you have).
    • Real-world MFA failures and successes are discussed in sidebars; e.g., Crypto.com 2022 2FA failures illustrate risks when second factors are compromised or infrastructure revokes factors; Optus 2022 demonstrates multi-factor policy deployment and geographic/regulatory considerations.
  • Location-based authentication and security questions:
    • Location and time-based cues can supplement authentication (e.g., login from expected location, office terminal).
    • Security questions (mother’s maiden name, childhood street, etc.) are commonly used but often weak; many public data sources can reveal answers.

2.1.4 Cookies and Web Authentication (Sidebar Concepts)

  • Cookies are used for session management and can enable automatic authentication in a browser session.
  • Security concerns:
    • Cookies can be stolen or replayed if not properly protected via encryption and integrity checks.
    • Cookies were not designed as security tokens; their integrity is not guaranteed, and servers should protect against eavesdropping.
  • Real-world guidance: cookies should be used with strong protections (e.g., TLS, httpOnly, secure flags) when used for authentication; improper handling can enable impersonation.

2.1.5 Practical Implications of Authentication

  • A balance between user convenience and security strength is essential; overly burdensome multi-factor schemes can drive users to weak practices or failure to use protections.
  • The right authentication approach depends on risk, sensitivity, and usability considerations; the chapter emphasizes tailoring authentication to the situation rather than applying a one-size-fits-all solution.

2.2 Access Control

  • Core question: How do we implement restrictions so that only authorized subjects perform authorized actions on objects?
  • Foundational model (Graham & Denning): A subject is allowed to access an object in a specific mode; only authorized accesses are allowed.
  • Key concepts:
    • Subjects: users or programs acting on behalf of users.
    • Objects: resources such as files, tables, memory, devices, network connections.
    • Access modes: read, write, modify, delete, execute, create, destroy, copy, export, import, etc.
  • Policy and enforcement: A policy guides which accesses are allowed; enforcement mechanisms implement those policies.
  • Access control mechanisms must be robust, easy to use, and efficient; they rely on clear policy definitions and regular policy updates.

2.2.1 Access Control Policies and Enforcement

  • Policy development should precede mechanism design: define higher-level security policy that drives concrete access rules.
  • Regularly check and revoke access rights as jobs and roles change; prevent stale or impersonation-based access.
  • Enforce least privilege: give users the minimum rights required to perform their tasks; reduces attack surface and limits blast radii.
  • Verify acceptable usage: not only should access be allowed, but the action itself must be legitimate (e.g., operations on a data structure like a stack).
  • Policy and enforcement implications extend beyond individual systems to networks and distributed environments.

2.2.2 Models of Access Control

  • Representation options (all equivalent in outcome, different in management):
    • Directory-based model (subject-centric): Each subject has a directory listing what objects they can access and how.
    • Access Control Matrix (ACM): A matrix with subjects as rows, objects as columns, and entries listing rights; usually sparse.
    • Access Control List (ACL): For each object, a list of subjects and their rights; per-object lists.
    • Privilege List (a.k.a. a directory for a subject): A row in the ACM showing rights the subject has across objects; easier revocation.
    • Capability-based model: Capabilities are unforgeable tokens granting rights to objects; can be passed (propagation) with rights; the OS can hold capabilities and hand out pointers to them; capabilities may be encrypted or include a transfer right.
  • Wildcards and scoping:
    • ACLs may use wildcards (e.g., Adams-Decl-*) to grant rights to groups or categories; first explicit matches override wildcards.
  • Domain concept in capabilities:
    • A process or thread runs in a domain (set of objects it can access); domains can be passed to subprocedures, with new capabilities created for the callee; domains may differ from caller domains.
  • The Reference Monitor concept (Anderson): A security component that enforces access control in a way that is always invoked, tamperproof, and verifiable.
    • Properties:
      1) Always invoked (monitors every access attempt).
      2) Tamperproof (cannot be bypassed or altered).
      3) Verifiable (policy mediation can be audited and reasoned about).
  • Protection mechanisms and hardware limitations:
    • OS-level enforcement is common but may defer to database managers or network devices for fine-grained or non-file objects.
    • Architecture choices (directory vs ACM vs ACL vs capability) have performance and usability trade-offs.

2.2.3 Access Control Models: Procedure-Oriented and Role-Based

  • Procedure-oriented access control: Access to an object is mediated by a controlling procedure; the procedure enforces legitimate use and may hide implementation details.
  • Role-Based Access Control (RBAC): Privileges are associated with roles, not individual users; users take on roles (e.g., administrator, employee) and gain the corresponding rights. This scales better when responsibilities change.
  • The chapter emphasizes that security design must balance simplicity, performance, and flexibility; increasingly complex mechanisms can introduce usability and performance challenges.

2.2.4 Granularity, Logging, and Management

  • Granularity: The level of detail at which access rights are defined (from coarse to fine-grained); finer granularity increases management complexity and performance overhead.
  • Access logging (audit logs): Record every access decision to aid post-incident analysis and forensics; logs must be balanced to capture useful detail without becoming unwieldy.
  • Tracking and revisiting access policies is essential to ensure policies still match organizational needs and to adjust for new risks and configurations.
  • The material emphasizes keeping a dynamic balance: complete lockdown harms availability; excessive access invites misuse.

2.3 Cryptography

  • Purpose: Introduce cryptography as a core security tool; this chapter provides rudimentary concepts and uses, with deeper coverage deferred to Chapter 12.
  • Key point: You don’t need to understand all internals of cryptography to use it effectively; you should understand its role and typical usage scenarios.
  • The general aim of cryptography is to protect confidentiality, integrity, and authenticity of data in transit and at rest, enabling secure communications and storage.
  • The chapter signals that cryptographic techniques underpin authentication, secure transport, data integrity, and many access-control implementations (e.g., digital signatures, certificates) but will be explored in more depth later.

2.3.1 Practical Concepts Tied to Security Principles

  • Encryption basics (brief, high-level): transforms data so that only intended receivers with the proper keys can recover the original content.
  • Signatures and certificates (mentioned as essential tools): enable non-repudiation, integrity, and trusted identity assertions in secure communications.
  • The broader implications for real-world systems include secure web sessions, email confidentiality, code signing, and trusted software distribution.

Summary of Key Takeaways

  • Authentication is the cornerstone of enforcing access control policies; without strong authentication, authorization cannot be reliably enforced.

  • The three bases of authentication provide multiple angles for safeguarding identity: something you know (passwords, PINs), something you are (biometrics), and something you have (tokens).

  • Passwords remain widespread but are notoriously weak due to guessability, social engineering, and password reuse; protections include salting, hashing, and, where possible, moving toward multi-factor approaches.

  • Biometrics bring convenience and resistance to sharing, but introduce challenges around false positives/negatives, enrollment, variability, and privacy concerns; combining multiple biometrics can mitigate some weaknesses.

  • Tokens and dynamic tokens offer strong resistance to replay attacks; skimming and copying remain concerns for static tokens; dynamic tokens (e.g., SecurID) provide per-authentication state changes.

  • Federated Identity Management and Single Sign-On help reduce the burden of managing multiple credentials across systems, but centralize trust and raise new risk considerations.

  • Multifactor authentication (MFA) improves security when factors are strong and properly managed, but can degrade usability if overcomplicated; scenarios like real-world MFA rollouts (2FA failures/successes) illustrate practical trade-offs.

  • Web cookies illustrate session management challenges and security trade-offs; cookies are not true authentication tokens and require careful protection to prevent impersonation.

  • Access Control aims to ensure that only authorized subjects can perform only authorized actions on authorized objects; policy must drive mechanism, not the other way around.

  • Access control models (directories, ACM, ACLs, capabilities) each have distinct management and performance characteristics; capabilities provide a powerful, fine-grained, possession-based approach that can be revocable and transferable with safeguards.

  • Reference Monitor concept provides a theoretical foundation for a tamperproof, always-invoked, verifiable enforcement mechanism for access control.

  • RBAC and Procedure-Oriented Access Control offer ways to manage permissions in scalable and secure ways, balancing control granularity with administrative load.

  • Cryptography underpins authentication, data integrity, and secure communications; the text sets expectations for practical usage and defers deep internals to a later chapter.

  • Equations and formulas mentioned (core definitions):

    • Sensitivity: ext{Sensitivity} = rac{TP}{TP+FN}
    • Specificity: ext{Specificity} = rac{TN}{FP+TN}
    • Positive Predictive Value: ext{PPV} = rac{TP}{TP+FP}
    • Negative Predictive Value: ext{NPV} = rac{TN}{TN+FN}
    • Prevalence: ext{Prev} = rac{TP+FN}{TP+FP+FN+TN}
    • Accuracy: ext{Accuracy} = rac{TP+TN}{TP+FP+FN+TN}
    • False Positive Rate: ext{FPR} = rac{FP}{FP+TN} = 1 - ext{Specificity}
    • True Positive Rate (same as Sensitivity): ext{TPR} = ext{Sensitivity} = rac{TP}{TP+FN}
    • ROC: relationship between FPR and TPR; Area Under Curve (AUC) ranges from 0 to 1, with 1 being perfect and 0.5 being random.

  • Practical artifacts referenced (for study): tables and sidebars (e.g., Table 2-6, Table 2-7, Table 2-8, etc.; Sidebars 2-1 through 2-16) provide concrete examples, empirical results, and real-world cases that illustrate the concepts above.

  • Overall goal of these chapters: build a foundation for understanding how authentication, access control, and cryptography work together to protect confidentiality, integrity, and availability in computer systems, and to prepare you to apply these principles across operating systems, networks, databases, and web platforms.