Usable Security and Authentication Lecture

Course Format and Pedagogical Design

• The course structure is explicitly designed as a interactive two-way discussion rather than a traditional lecture.

• The primary goal of the classroom environment is active discussion where students share perspectives and collaboratively facilitate learning.

• Physical space trade-offs:

  • The current smaller physical environment accommodates fewer students compared to a traditional lecture hall.

  • Moving to a traditional lecture hall could accommodate approximately $15$ to $20$ additional students, but it alters the interactive dynamic.

• Instructional techniques to stimulate student participation include the intentional use of extended pauses, though direct student response remains variable.

Academic Context and Usable Security Research

• Notable Usable Security Papers and Authors:

  • Rational Rejection of Security Advice by Cormac Herley and Paul van Oorschot.

  • Key graphical password literature co-authored by Paul van Oorschot.

• Research Institutions in Usable Security:

  • Carnegie Mellon University has historically been recognized as the leading institution in usable security research.

  • Carleton University (located in Ottawa, Canada) was historically recognized as having the second most active usable security research group globally during its peak activity era around $2012$.

The UDS Framework for Authentication Evaluation

• Based on the seminal research paper The Quest to Replace Passwords by Joseph Bonneau and co-authors.

The Password Paradox

• Passwords possess severe, well-documented security vulnerabilities (susceptibility to guessing, phishing, credential leaks, and poor user reuse habits).

• Despite an abundance of proposed technological alternatives (biometrics, hardware tokens, graphical passwords, password managers, federated login), passwords remain the dominant authentication mechanism across the web.

• The paradox exists because evaluating whether an authentication scheme is "better" requires evaluating multiple conflicting operational dimensions rather than security alone.

Structure of the UDS Framework

• The UDS Framework evaluates authentication schemes across three core dimensions:

  • Usability (U): Can users learn the system, operate it efficiently, and recover from errors or lost credentials?

  • Deployability (D): Can service providers realistically adopt, integrate, and maintain the system at scale?

  • Security (S): Can the system resist common technical attacks while protecting user privacy?

• System Improvement Rule: An authentication scheme is only genuinely superior if it yields a net positive improvement across the whole system. Significantly degrading one dimension to enhance another does not constitute a viable replacement.

The $25$ Framework Benefits

• The UDS framework establishes $25$ explicit evaluation benefits categorized across the three core dimensions:

  • Usability: $8$ specific benefits.

  • Deployability: $6$ specific benefits.

  • Security: $11$ specific benefits.

Usability Dimension ($8$ Benefits)

• Cognitive Load:

  • Memoryless (users do not need to memorize complex secret strings).

  • Easy to learn (intuitive operational flow for novice users).

• Operational Friction:

  • Scalable across many accounts without increasing user strain.

  • Requires minimal physical effort per authentication event.

  • Does not require carrying additional physical objects or dedicated token devices.

• Recovery and Reliability:

  • Low internal error rates.

  • Straightforward credential recovery mechanisms in the event of lost authenticators.

  • Operational stealth/background functionality (authentication should not distract from the user's primary goal).

Deployability Dimension ($6$ Benefits)

• Broad Accessibility: Accessible to diverse user populations without requiring specialized hardware.

• Low Cost: Negligible deployment and maintenance cost per user for the service provider.

• Browser Integration: Direct compatibility with existing standard web browsers without requiring custom plugins or client software.

• Server Integration: Compatibility with standard server infrastructure and protocols without requiring radical backend overhauls.

• Maturity: Technological stability and standard availability.

• Non-proprietary Nature: Based on open standards without vendor lock-in or licensing fees.

Security and Privacy Dimension ($11$ Benefits)

• Attack Resistance:

  • Resilient to physical observation (shoulder surfing).

  • Resilient to targeted guessing (both throttled and unthrottled attack scenarios).

  • Resilient to targeted impersonation using personal knowledge.

  • Resilient to phishing and man-in-the-middle attacks.

  • Resilient to credential theft and database leaks at the verifier/server level.

  • Resilient to internal observation (malware or keyloggers on the client device).

• Privacy and Identity:

  • Unlinkability across different services (prevents cross-site tracking).

  • Independence from trusted third parties.

  • Requirement of explicit user consent per authentication event.

Baseline Evaluation: Passwords vs. Alternative Schemes

Password Evaluation Summary

• Deployability Strengths:

  • Near-zero cost per user.

  • Universal compatibility across every web browser and server platform.

  • No physical hardware required.

  • Well-established, familiar recovery infrastructure.

• Security Weaknesses:

  • Highly vulnerable to brute-force guessing, credential stuffing, phishing, and server leaks.

  • Password reuse amplifies blast radius across multiple services.

• Usability Weaknesses:

  • Poor memory scalability; humans cannot memorize unique, complex passwords for dozens of accounts.

Why Passwords Persist

• No alternative authentication scheme evaluated in early comparative studies completely dominated passwords across all three UDS dimensions simultaneously.

• Historical Alternative Trade-offs:

  • Hardware Tokens: Strong security, but introduce high financial costs, deployment barriers, and require users to carry a physical object.

  • Early Biometrics: Reduced memory load, but suffered from high error rates, non-replaceability if compromised, and lack of cross-site unlinkability.

  • Federated Login (OAuth / SSO): High user convenience, but introduces third-party dependency and privacy/tracking concerns.

• Main Finding: Deployability is the primary barrier to replacing passwords. Passwords survive not due to superior security, but because the cost, inconvenience, and operational friction of replacing the existing global password infrastructure outweigh the security benefits for most organizations.

Limitations of the UDS Evaluation Framework

• The list of $25$ benefits is non-exhaustive.

• Weighting of benefits is context-dependent (e.g., financial institutions prioritize security over deployability, whereas public forums prioritize low-friction onboarding).

• Framework scoring involves subjective qualitative judgments across specific implementation criteria.

Historical Evolution of Authentication Technologies

Modern Biometrics Redesign

• Historical Implementation (circa $2012$):

  • Biometrics were treated directly as the authentication secret/credential itself (e.g., transmitting raw fingerprint representations over the network).

  • Caused severe security flaws: raw biometric traits could not be revoked or reset if stolen, and cross-site tracking was trivial.

• Modern Implementation Architecture:

  • Biometrics are local gatekeepers used solely to unlock a locally generated private key stored in a hardware security module.

  • Hardware Security Modules used in modern client hardware:

  • Apple Ecosystem: Secure Enclave.

  • PC / Windows Ecosystem: Trusted Platform Module (TPM).

  • Android Ecosystem: Hardware-backed KeyStore / Trusted Execution Environment (TEE).

  • Raw biometric data (e.g., Face ID $3\text{D}$ depth maps, Touch ID ridge data) never leaves the device's secure enclave API.

  • Modern optical and infrared sensors require active liveness verification (e.g., eye-tracking for open eyes in Face ID) to prevent spoofing.

Federated Login Adoption

• Ubiquitous implementations: "Sign in with Google", "Sign in with Apple".

• Trade-offs in practice:

  • Usability: Extremely high convenience; eliminates account creation steps.

  • Security: Offloads authentication security to highly specialized providers equipped to handle threat monitoring.

  • User Concerns: Reliance on third-party identity providers introduces cross-site tracking risks, identity linkage, and potential central points of failure.

Passkeys and Modern Cryptographic Authentication

• Passkeys represent the modern industry standard designed to replace traditional password systems using public-key cryptography and open standards (WebAuthn / FIDO2).

Technical Architecture and Operational Flow

• Key Generation & Registration:

  • Upon creating an account, the user's client device generates an asymmetric cryptographic key pair consisting of a Public Key and a Private Key.

  • The Public Key is transmitted to the service provider's server and stored publicly.

  • The Private Key is stored inside the local hardware security module (Secure Enclave / TPM).

• Cloud Syncing:

  • Passkeys are end-to-end encrypted and synced across user devices via platform password managers (e.g., Apple Passwords / iCloud Keychain, Google Password Manager).

  • The private key is synced securely to authorized client devices but cannot be extracted in plaintext via standard APIs.

• Authentication Mechanism (Challenge-Response):

  1. The server issues a unique cryptographic challenge to the client device upon a login request.

  2. The client prompts the user for local biometric authorization (Face ID, Touch ID) or local device PIN.

  3. Upon successful local authorization, the secure enclave signs the server's challenge using the stored Private Key.

  4. The signed challenge response is returned to the server.

  5. The server verifies the cryptographic signature using the registered Public Key.

Technical Advantages of Passkeys

• Phishing Resistance: Key pairs are cryptographically bound to the specific domain name (origin). A phishing website operating on a spoofed domain cannot trigger signature generation for the legitimate service's key pair.

• Cryptographic Strength: High-entropy key generation eliminates brute-force, dictionary, and automated guessing attacks.

• Server Leak Immunity: Servers only store public keys; a database breach at the verifier yields no actionable secrets to attackers.

Comprehensive Evaluation: Passkeys vs. UDS Criteria

Human-Centered Security Research Guidelines

• Scope of Student Individual Research Projects:

  • Open-ended methodology focusing on human-centered security data collection.

  • Acceptable methodological approaches: user studies, structured interviews, surveys, or usability testing.

• Participant Criteria:

  • Sample size: Target cohort of $5$ to $10$ participants.

  • Eligible demographics: Any consenting adult participant ($\ge 18$ years old).

  • Peer recruitment: Peer recruiting within the classroom cohort is explicitly encouraged due to efficiency and practical execution benefits.

• Data Analysis Considerations:

  • Studies with small sample sizes ($5$ to $10$ participants) cannot yield statistically significant quantitative metrics.

  • High-quality qualitative feedback (e.g., direct quotes, verbalized user thought processes, behavioral observations) holds high academic value in small-sample human-computer interaction studies.

Questions & Discussion

• Question: Why avoid using federated logins ("Sign in with Google/Apple") for personal accounts online?

  • Response: Primary resistance stems from privacy concerns, uncertainty regarding background data linkage/tracking between the identity provider and third-party sites, and a desire to isolate corporate/tech platform entities from personal online activity. Many users prefer guest checkout options to minimize data footprint.

• Question: Are quantitative comparisons between two small sub-groups valid for the individual research assignment?

  • Response: Yes. While formal statistical significance tests cannot be run on very small groups, presenting comparative descriptive metrics alongside thorough qualitative observation is entirely acceptable for the project scope.