Broken Access: On the Challenges of Screen Reader Assisted Two-Factor and Passwordless Authentication

This paper introduces the AWARE evaluation framework to systematically analyze screen reader-assisted authentication, revealing that current two-factor and passwordless methods contain significant accessibility flaws that expose blind and visually impaired users to various security vulnerabilities.

The Gist

Imagine you are trying to enter a high-security building. You have a special key (your password) and a second key (a code sent to your phone). For most people, this is easy: they read the screen, type the code, and walk in.

But for blind or visually impaired people, they don't "see" the screen. Instead, they use a Screen Reader. Think of a Screen Reader as a robotic tour guide that sits on their shoulder, reading everything on the screen out loud so they know where to go and what to do.

This paper is a report card on how well these "robotic tour guides" are doing their jobs when it comes to security. The researchers found that while the guides are great at reading news articles, they are terrible at reading security instructions, leaving blind users wide open to hackers.

Here is the breakdown of the study in simple terms:

1. The Problem: The Guide is Confused

The researchers created a new testing tool called AWARE (Authentication Workflows Accessibility Review and Evaluation). Think of AWARE as a quality control inspector for these robotic guides.

They tested popular security methods (like Google, Microsoft, and Duo) to see if the guides could clearly explain the steps to a blind user.

• The Result: The guides often mumbled, skipped important words, or read the wrong things.
• The Analogy: Imagine a tour guide trying to tell you to "Turn left at the red door," but instead, they say, "Turn left at the... uh... red... thing." You might turn left at the wrong door and end up in the wrong building.

2. The Specific Glitches

The study found three main ways the "tour guides" fail:

• The "Math Problem" (NPO): When a security code is "1234," the guide shouldn't say "One thousand, two hundred, thirty-four." It should say "One, two, three, four." Many guides say the long version, which is impossible to type quickly before the code expires.
• The "Silent Room" (UCO): Sometimes, the security code appears on the screen, but the guide simply refuses to read it out loud because the app is "closed off." The user is left waiting for a voice that never comes.
• The "Double Talk" (CBI): Imagine the guide is reading instructions, but suddenly your phone rings with a security call. The guide stops talking, the phone rings, and then the guide tries to start again but gets confused. The user misses the critical instruction.

3. The Security Nightmares

Because the guides are confused, blind users are vulnerable to specific types of attacks:

• The "Phishing" Trap: Hackers create fake websites that look real. A sighted person sees the URL is bankofamerica.com vs. bankofamerica-scam.com. A blind person relies on the guide to read the URL. The study found that guides often read these fake URLs in a way that sounds identical to the real one. It's like a con artist wearing a disguise that sounds exactly like your friend's voice.
• The "Fatigue" Attack: Hackers spam the user with hundreds of "Approve Login?" notifications. A sighted person might get annoyed and stop. A blind person, relying on the guide, might get overwhelmed by the noise and accidentally say "Yes" just to make the noise stop.
• The "Shoulder Surfing" Risk: If a blind person is using a computer and a phone at the same time (to get a code), they might wear headphones for the computer but leave the phone on speaker. A hacker standing nearby can hear the code being read aloud over the phone speaker.

4. The "Two-Device" Danger Zone

The study found that the most dangerous situation is when a user has to use both a computer and a phone at the same time.

• The Analogy: It's like trying to listen to two different radio stations playing at the same time. The "tour guides" on both devices start talking over each other, creating a chaotic mess where the user can't hear the security instructions clearly. This makes it very easy for a hacker to slip in.

5. What Can Be Done?

The researchers aren't just pointing out problems; they are offering a blueprint for fixes:

• For App Designers: Stop using confusing visual layouts. Make sure the "robotic guides" can actually read the security buttons and codes clearly.
• For Guide Developers: Program the guides to be smarter. If they detect a fake website, they should shout a warning! If they hear two notifications at once, they should alert the user.
• The Best Current Option: The study suggests that using FIDO security keys (physical USB keys) with a specific screen reader (NVDA) is currently the safest and most accessible method, as it relies less on reading confusing text and more on physical actions.

The Bottom Line

Right now, the digital world is building high-security doors, but the "keys" for blind people are often broken or missing. This paper is a wake-up call: Security cannot exist without Accessibility. If we don't fix how these "robotic guides" talk to blind users, we are leaving the front door unlocked for them while locking it for everyone else.

Technical Summary

Here is a detailed technical summary of the paper "Broken Access: On the Challenges of Screen Reader Assisted Two-Factor and Passwordless Authentication."

1. Problem Statement

While web services have expanded opportunities for blind and visually impaired (BVI) users, current authentication mechanisms (2FA, MFA, and passwordless systems) are predominantly designed for sighted users. This creates a critical security and accessibility gap.

• The Core Issue: BVI users rely on screen readers (e.g., JAWS, VoiceOver, TalkBack) to interact with digital services. However, the interaction between screen readers and modern authentication workflows often results in:
  • Inaccessible Instructions: Critical security details (like One-Time Passwords or service names) are not conveyed clearly or at all.
  • Security Vulnerabilities: The inability of screen readers to distinguish subtle differences in URLs or detect malicious overlays makes BVI users highly susceptible to phishing, shoulder surfing, and concurrent login attacks.
• The Gap: Previous research focused on general usability or specific password alternatives (e.g., BraillePassword) but failed to systematically evaluate widely deployed, real-world authentication methods (Google, Microsoft, Duo, FIDO) from the perspective of screen reader-assisted security.

2. Methodology: The AWARE Framework

The authors introduced the Authentication Workflows Accessibility Review and Evaluation (AWARE) framework. This is a semi-automated tool designed to evaluate security and accessibility prior to costly user studies.

• Process:
  1. Recording: Screen reader audio outputs are recorded while traversing authentication workflows (general text vs. authentication instructions).
  2. Transcription: Audio is converted to text using the IBM Watson speech-to-text engine.
  3. Analysis: The generated text is compared against the original source text using cosine similarity (via the pysimilar library and TF-IDF vectorization) to calculate Comprehensibility.
  4. Attack Simulation: The framework simulates specific threats (Phishing, Concurrent Login, Notification Fatigue, Shoulder Surfing, FIDO-specific attacks) to test system resilience.
• Test Settings: The study evaluated three distinct environments:
  1. Terminal (PC) only: Using JAWS, NVDA, Dolphin, and ChromeVox.
  2. Smartphone only: Using VoiceOver (iOS) and TalkBack (Android).
  3. Simultaneous Use: PC and Smartphone used together (common for receiving OTPs on a phone while logging in on a PC).
• Subjects: 12 real-world authentication methods (including Google, Duo, Microsoft, FIDO/Titan Key) were tested against 6 screen readers.

3. Key Contributions

1. Conceptualization of Screen Reader Assisted Authentication: The paper formally models the problem, identifying that the "screen reader" is a critical intermediary that can introduce vulnerabilities if not properly integrated with authentication protocols.
2. The AWARE Framework: A novel, cost-effective methodology that allows designers to identify accessibility and security flaws early in the development lifecycle, reducing the need for immediate, resource-intensive user studies with BVI participants.
3. Systematic Evaluation: A comprehensive assessment of 12 authentication variants across 6 screen readers, revealing that no observed scenario was free from significant weaknesses.

4. Key Results and Findings

A. Accessibility Metrics (Communicability & Comprehensibility)

• Low Comprehensibility: While screen readers achieve >74% comprehensibility for general text (e.g., news articles), this drops drastically for authentication workflows.
  • Only 22 out of 33 cross-setting combinations achieved <50% comprehensibility for authentication instructions.
  • Some methods (e.g., GAuth via JAWS) scored as low as 4.45%.
• Critical Communication Failures (Notations defined in the paper):
  • CBI (Conflict Between Instructions): Screen readers read conflicting instructions simultaneously (e.g., a phone call for OTP interrupting a screen reader instruction), often causing headphones to disconnect and exposing audio to shoulder surfers.
  • NPO (Numeric Pronunciation of OTP): Screen readers often pronounce "1234" as "one thousand two hundred thirty-four" instead of digit-by-digit, making OTPs unusable.
  • UCO/UCSP/UCEOB: Screen readers fail to communicate OTPs, security prompts, or elements outside the browser (e.g., Windows Security dialogs for FIDO).

B. Vulnerability Analysis

The study identified severe vulnerabilities across all tested scenarios:

• Phishing: Screen readers pronounce top-level domains as whole words (e.g., "bankofamerica" vs. "bankoffamerica" sound identical), making it impossible for BVI users to detect phishing URLs.
• Concurrent Login: Attackers can trigger a login request that overrides the legitimate notification. Screen readers often read the most recent notification, causing the user to inadvertently approve the attacker's session.
• Notification Fatigue: Continuous push notifications (MFA spamming) overwhelm users. Screen readers struggle to distinguish between "Approve" and "Deny" in rapid succession, leading to "fatigue attacks" where users approve malicious requests out of exhaustion.
• Shoulder Surfing: In simultaneous PC/Smartphone setups, if the user uses headphones on one device but not the other, or if a phone call for OTP interrupts the screen reader, the OTP is spoken aloud, allowing nearby attackers to capture it.
• FIDO/Passkeys:
  • Display Overlay Attacks: Some screen readers (JAWS, Dolphin) read false information overlaid by attackers, while others (NVDA) bypass it.
  • Cross-Service Attacks: Screen readers often fail to read the specific service name or browser context in security dialogs, allowing attackers to trick users into approving authentication for a different service.
  • Downgrading: Attackers can exploit screen reader limitations to force a downgrade from FIDO to weaker OTP-based 2FA.

C. Specific Method Performance

• Push-Based (Duo, Google, Microsoft): Highly vulnerable to concurrent login and notification fatigue. Microsoft's "Select-Confirm" is slightly more secure but still suffers from delays and conflicts.
• OTP (Text/Call): Highly vulnerable to shoulder surfing and NPO issues. Phone calls often disconnect headphones, creating a major security risk.
• FIDO (Titan Key): Offers better usability but suffers from "Unable to Communicate Prompts" (UCSP) issues, where users cannot verify the service name before authenticating.

5. Significance and Recommendations

• Significance: The paper demonstrates that current "secure" authentication methods are effectively broken for blind and visually impaired users. The reliance on screen readers introduces a new attack surface that current security protocols do not account for.
• Recommendations for Designers:
  • Clear Instructions: Provide concise, screen-reader-friendly written instructions at every step.
  • Conflict Management: Avoid generating phone calls or other audio interruptions while the screen reader is active.
  • Service Identification: Ensure screen readers can clearly announce the service name and domain before authentication.
  • Phishing Detectors: Integrate URL detection and warning systems directly into screen readers.
• Best Practice Identified: The study suggests that FIDO (Passkeys) used with the NVDA screen reader currently offers the best balance of accessibility and security among the tested options, though significant improvements are still needed.

Conclusion

The authors conclude that achieving equitable digital participation requires cross-disciplinary collaboration between security experts, disability services, and HCI researchers. The AWARE framework provides a vital tool for identifying these "broken access" points before deployment, ensuring that security measures do not inadvertently exclude or endanger the blind and visually impaired community.