Source-linked AI summary
Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound
Nikolaos Karapanos, Claudio Marforio, Claudio Soriente, Srdjan Capkun
TL;DR
Sound-Proof targets the usability and deployability barriers that make users reluctant to use two-factor authentication. It verifies phone proximity through transparent ambient-audio comparison using current devices and browsers. Evaluations found strong usability across settings, while the design excludes co-located targeted attacks.
Problem
Users often prefer password-only authentication because 2FA adds phone interaction, while interaction-free proposals require software or hardware not supported by current devices and browsers.
Method
Sound-Proof compares ambient recordings from the login computer and the user’s phone to verify proximity, using transparent operation with current phones and major browsers without plugins.
Results
Participants rated Sound-Proof more usable than Google 2-Step Verification, and most would use it when 2FA was optional; it also worked indoors, outdoors, and with phones in pockets or purses.
Takeaways & Limitations
Sound-Proof improves the usability and deployability of 2FA and may foster broader adoption.
Takeaways & Limitations
Sound-Proof is not designed to protect against targeted attacks where an attacker is co-located with the victim and has the victim’s credentials.
Abstract
from arXiv · showhide
Two-factor authentication protects online accounts even if passwords are leaked. Most users, however, prefer password-only authentication. One reason why two-factor authentication is so unpopular is the extra steps that the user must complete in order to log in. Currently deployed two-factor authentication mechanisms require the user to interact with his phone to, for example, copy a verification code to the browser. Two-factor authentication schemes that eliminate user-phone interaction exist, but require additional software to be deployed. In this paper we propose Sound-Proof, a usable and deployable two-factor authentication mechanism. Sound-Proof does not require interaction between the user and his phone. In Sound-Proof the second authentication factor is the proximity of the user's phone to the device being used to log in. The proximity of the two devices is verified by comparing the ambient noise recorded by their microphones. Audio recording and comparison are transparent to the user, so that the user experience is similar to the one of password-only authentication. Sound-Proof can be easily deployed as it works with current phones and major browsers without plugins. We build a prototype for both Android and iOS. We provide empirical evidence that ambient noise is a robust discriminant to determine the proximity of two devices both indoors and outdoors, and even if the phone is in a pocket or purse. We conduct a user study designed to compare the perceived usability of Sound-Proof with Google 2-Step Verification. Participants ranked Sound-Proof as more usable and the majority would be willing to use Sound-Proof even for scenarios in which two-factor authentication is optional.
1 Introduction
Sound-Proof addresses the usability burden and deployment barriers that keep users from adopting two-factor authentication. It verifies phone proximity through transparent ambient-audio comparison and was evaluated as usable across settings and against Google 2-Step Verification.
- Most users still prefer password-only authentication because conventional 2FA typically requires interacting with a phone.
- Sound-Proof verifies the phone’s proximity to the login computer by comparing ambient audio recorded by their microphones, without user-phone interaction.Recording and comparison are transparent to the user.
- Sound-Proof is deployable with current phones and major browsers without additional browser plugins.It works with HTML5-compliant browsers implementing WebRTC.
- Sound-Proof is not designed to protect against targeted attacks in which an attacker is co-located with the victim and has the victim’s credentials.
- A prototype was implemented for both Android and iOS and evaluated indoors, outdoors, and with the phone in a pocket or purse.
- Participants ranked Sound-Proof more usable than Google 2-Step Verification, and most would use it when 2FA was optional.The difference in perceived usability was statistically significant.
2 Assumptions and Goals
The paper assumes browser-based authentication with software tokens and a remote adversary who has obtained the victim’s credentials. Its goals are phone-interaction-free usability and broad deployability, while excluding several powerful attack settings.
- The system model uses browser-based web authentication in which a server employs software tokens on users’ phones as a second factor.
- The threat model assumes a remote adversary who obtained the victim’s username and password and seeks to authenticate as that user.
- The analysis assumes the adversary cannot compromise the victim’s phone or computer, because either compromise defeats the corresponding 2FA protection.
- Security scope: The paper excludes targeted co-located attacks and Man-in-the-Middle adversaries from its protection goals.
- Usability: The usability goal is password-only-style authentication without asking users to interact with, pick up, or remove their phone.
- Deployability: The deployability goal requires common smartphones, computers, and browsers without additional computer software or browser plugins.
3 Alternative Approaches
Existing 2FA approaches reduce interaction or improve security in different ways, but the paper identifies deployment, hardware, setup, usability, and security limitations that prevent them from meeting its goals.
- Traditional 2FA: Hardware tokens require users to carry and interact with a token and may impose shipping costs on service providers.
- Traditional 2FA: Verification-code schemes such as Google 2-Step Verification require users to copy a code from the phone to the browser.
- Traditional 2FA: Push-based schemes still require users to interact with the phone to authorize a login.
- Short-range communication: Bluetooth-based proposals eliminate user interaction but require browser Bluetooth APIs that are not currently available on browsers.
- Short-range communication: Authy provides seamless Bluetooth-based 2FA but requires extra software on the computer.
- Short-range communication: WiFi-based approaches require both devices to share a network and may require repeated setup on each new computer.
- Short-range communication: NFC is uncommon on commodity computers, lacks browser APIs, and still requires the user to hold the phone near the computer.
- Near-ultrasound: Near-ultrasound approaches can fail with in-band noise, require sufficient speaker volume, and may be unpleasant for people or animals hearing above 18kHz.
4 Background on Sound Similarity
Sound-Proof compares ambient recordings using frequency-band filtering and cross-correlation, combining spectral resolution with time-domain similarity. The resulting score accommodates amplitude differences and unknown timing offsets.
- Audio similarity is framed as matching noisy recordings through robust features, including one-third octave bands and cross-correlation.One-third octave bands preserve time-domain representation while providing high frequency resolution.
- One-third octave filtering divides the audible range into 32 standardized bands, representing frequencies from 16Hz through 20kHz.
- Cross-correlation measures similarity between two discrete time series as a function of the lag applied to one signal.The signals are modeled as n-point discrete time series.
- Normalized cross-correlation accommodates different signal amplitudes, with values of 1, −1, and 0 indicating matching shape, opposite-sign shape, and no correlation.Normalization uses the signals’ autocorrelation terms.
- When timing is unknown, the method uses the absolute maximum cross-correlation over candidate lags.The computation can be accelerated through the cross-correlation theorem and inverse Fourier transform.
5 Sound-Proof Architecture
Sound-Proof authenticates proximity by having the phone and computer record ambient noise, then letting the phone compare the recordings and report co-location to the server. Encryption protects cleartext audio from being uploaded, while threshold checks determine legitimacy.
- Sound-Proof uses phone–computer proximity as the second factor, verified by comparing ambient audio recorded through both devices’ microphones.Recording and comparison are designed to be transparent to the user.
- The computer encrypts its recording under the phone’s public key; the phone decrypts and compares it locally, never uploading its own recording to the server.Communication between phone and computer is proxied through the server rather than using short-range radio.
- During login, the browser and phone record for t seconds, synchronize timestamps with the server, and send the encrypted browser sample to the phone through the server.
- The phone accepts the login when both samples exceed τdB in average power and their similarity score exceeds τC.The phone then informs the server that the devices are co-located and the login is legitimate.
- In quiet environments, the otherwise transparent procedure requires the user to generate noise, such as by clearing their throat.
- Sound-Proof is not designed to protect against a co-located attacker who has the victim’s credentials and can capture the victim’s ambient sound.Resistance to co-located attackers would require a secure phone–computer channel or user–phone interaction, both of which impose usability burdens.
6 Prototype Implementation
The prototype supports Android and iOS phones and tested major browsers through WebRTC. Its two-factor verification adds roughly five seconds on average, with measured overhead varying by network type.
- The prototype supports Android and iOS phones and was tested with Chrome, Firefox, and Opera using WebRTC’s navigator.getUserMedia() API.The implementation uses platform-specific mobile audio-processing technologies, including ARM NEON optimizations.
- 4677ms (± 181ms) over WiFi and 4944ms (± 233ms) over Cellular were the average times to complete 2FA verification.
7 Evaluation
The evaluation collected 2,007 login attempts across environments, user activities, device positions, and hardware, then optimized Sound-Proof’s parameters using FRR and FAR. The resulting configuration achieved an ERR of 0.0020, while tests showed low rejection rates across varied conditions and low FAR even when attackers guessed the victim’s environment.
- Evaluation setup: 2,007 login attempts covered environments, user activities, phone positions, and phone and computer models.The study collected 5–15 attempts per setting over four weeks, producing 4,014 audio samples.
- Parameter selection: The parameter search optimized τdB, ℓmax, B, and τC using false rejection and false acceptance rates.False rejection denotes rejected legitimate logins, while false acceptance denotes accepted fraudulent logins.
- Parameter selection: 0.0020 ERR was obtained with B = [50Hz−4kHz] at τC = 0.13.The selected configuration also used τdB = 40dB and ℓmax = 150ms; bands above 4kHz performed worse.
- Environment and activity: Sound-Proof had no legitimate-login rejections in Music, Lecture, or TV environments, while FRR ranged from 0.003 to 0.006 in Office, TrainStation, and Cafe.The reported FRRs were 0.003 for Office, 0.003 for TrainStation, and 0.006 for Cafe.
- Environment and activity: FRR was 0.005 when users were silent, 0.002 when coughing, and 0 when speaking or whistling.The activity results covered 579 silent, 529 coughing, 541 speaking, and 353 whistling logins.
- Advanced attack scenarios: 0 FAR occurred at 4, 8, and 12 meters from a TV, whereas logins were rejected when the phone was in another room behind a closed door.The TV noise level was measured at 50dB, and each distance was tested with 20 login attempts.
- Advanced attack scenarios: The FAR was 0.025 in Office and 0.001 in Cafe when attackers correctly guessed the victim’s environment.The reported counts were 1,194 over 47,250 Office attempts and 32 over 56,994 Cafe attempts.
8 User Study
The user study compared Sound-Proof with Google 2-Step Verification using randomized repeated-measure login tasks and usability questionnaires. Participants rated Sound-Proof more usable, quicker, and less burdensome, with stronger acceptance when 2FA was optional.
- Study design: The study randomized each participant’s use of Sound-Proof and Google 2-Step Verification, collecting SUS ratings after each login.The SUS ranges from 0 to 100, with higher scores indicating better usability.
- Usability results: 91.09 versus 79.45: mean SUS scores favored Sound-Proof over Google 2SV, with a statistically significant difference.A one-way ANOVA reported F(1,31) = 21.698 and p < .001.
- User acceptance: 84% versus 47% would use Sound-Proof versus Google 2SV when 2FA was mandatory, while optional-use willingness was 78% versus 19%.Sound-Proof’s acceptance declined by 6 percentage points when 2FA changed from mandatory to optional.
- Contextual comfort: Comfort using Sound-Proof varied by setting, from 95% at home to 50% in a library, while Google 2SV received 82–91% comfort across scenarios.The study considered home, workplace, cafe, and library settings.
- Qualitative feedback: Participants’ comments described Sound-Proof as user-friendly and valued its lack of phone interaction.The post-test questionnaire covered aspects not captured by the SUS.
9 Discussion
The discussion addresses Sound-Proof’s deployment requirements, environmental constraints, and fallback options. It also considers extensions and cases in which the system may accept a login from the same device.
- Requirements: Sound-Proof requires a phone application and data connection but no additional computer software, working with HTML5 browsers that implement WebRTC.Chrome, Firefox, and Opera supported WebRTC at the time described.
- Privacy: The paper notes that microphone-enabled websites may record ambient noise when users visit their pages, although browsers request permission and display recording alerts.This creates a privacy-relevant consideration for deployment.
- Environmental constraints: Quiet environments can cause Sound-Proof to reject a login when either audio sample falls below τdB.The website can prompt the user to create noise, or offer code-based 2FA as a fallback.
- Fallback: Code-based 2FA provides a fallback when the environment is quiet, the user avoids making noise, or the phone lacks data connectivity.The webpage can use Sound-Proof by default while allowing verification-code login.
- Extensions and edge cases: Smartwatches are proposed as a possible way to lower false rejections, while same-device login may be accepted because both captures use the same microphone.The smartwatch claim is presented as speculation, whereas the same-device behavior follows from the shared microphone.
- Comparative analysis: Sound-Proof is compared with Google 2SV, PhoneAuth, and FBD-WF-WF using a framework that records whether usability and security benefits are provided or somewhat provided.The table uses Y for provided and S for somewhat provided.
10 Related Work
Related work uses ambient audio or multiple sensors to establish device proximity, but prior approaches make stronger hardware, robustness, or deployment assumptions. Sound-Proof is positioned as a browser-compatible alternative focused on practical authentication.
- Audio proximity detection: Halevi et al. use audio cross-correlation and machine learning to detect whether two devices were recorded at the same location for NFC relay protection.Their experiments claimed zero false acceptances and false rejections but assumed identical device hardware.
- Comparison: The related approaches demonstrate audio’s relevance to proximity verification while exposing trade-offs involving hardware assumptions, false rejections, sensor requirements, and outdoor operation.These comparisons motivate Sound-Proof’s emphasis on deployability and practical web authentication.
- Multi-sensor approaches: Truong et al. combine GPS, Bluetooth, WiFi, and audio for co-location detection because their audio-only solution produced 20% false rejections.Their approach also requires a time budget that may be unavailable for web authentication.
- Audio-derived keys: Another scheme derives cryptographic keys from ambient audio between co-located devices, but experiments found key derivation hardly feasible outdoors.The scheme uses audio fingerprinting and fuzzy commitments to accommodate recording differences.
11 Conclusion
The paper concludes that Sound-Proof makes two-factor authentication more usable and deployable by removing phone interaction and using major browsers. Its user study found higher usability than Google 2-Step Verification and substantial willingness to use it when 2FA is optional.
- Conclusion: Sound-Proof requires no user-phone interaction and can already be used with major browsers.The conclusion presents these as central usability and deployability properties.
- Conclusion: Participants rated Sound-Proof more usable than Google 2-Step Verification, and most would use it for services where 2FA was optional.The conclusion reiterates the study’s principal comparative and adoption findings.
- Conclusion: The paper reports that Sound-Proof works with the phone in a pocket or purse and in both indoor and outdoor settings.These are the environmental conditions highlighted in the conclusion.
- Implication: The authors conclude that improved usability and deployability can foster large-scale adoption of 2FA.This is the paper’s stated practical implication.
- Measurement: The appendix documents the SUS questionnaire items, which use a 5-point Likert scale from Strongly Disagree to Strongly Agree.The items cover perceived complexity, ease of use, confidence, and related usability judgments.
B Post-test Questionnaire
The post-test questionnaire used 5-point Likert-scale items to assess participants’ perceptions of the audio-based and code-based methods. Items covered speed, willingness to use each method, and comfort across home, workplace, and cafe settings.
- The questionnaire used a 5-point Likert scale ranging from Strongly Disagree to Strongly Agree.
- Participants rated whether the audio-based and code-based methods were quick.
- Participants reported willingness to use each method when second-factor authentication was mandatory or optional.
- Participants rated comfort using the audio-based method at home, at work, and in a cafe.
- Participants rated comfort using the code-based method at home, at work, and in a cafe.
C User Comments
Participants’ comments commonly described Sound-Proof as faster, simpler, and automatic because it avoids handling the phone. Some still viewed Google 2-Step Verification as more secure or noted discomfort using Sound-Proof in public places.
- Participants described Sound-Proof as faster, automatic, and less burdensome while increasing security without extra actions.
- Public-place use could feel awkward to some participants until Sound-Proof became widespread.
- Avoiding phone handling was identified as a major advantage of the audio-based method.
- A security-conscious participant already using 2FA said Sound-Proof was easier and would motivate switching.
- One participant preferred Google 2SV for perceived security despite describing Sound-Proof as seamless.