SPIES Lab, Computer Science and Engineering

Sound-Danger

Dangers of Second Factor Login based on Ambient Audio

Reducing user burden underlying traditional two-factor authentication constitutes an important research effort. An interesting representative approach, Sound-Proof, leverages ambient sounds to detect the proximity between the second factor device (phone) and the login terminal (browser). Specifically, during the login session, the browser and the phone each record a short audio clip, and the login is deemed successful only if the two recorded audio samples are highly correlated with each other (and the correct password is supplied). Except of entering the password, Sound-Proof does not require any user action (e.g., transferring PIN codes or even looking-up the phone) – mere proximity of the phone with the terminal is sufficient to login. It may also work even if the phone is inside a purse or pocket. A compelling deployability feature of Sound-Proof is that it does not require browser plugins or any changes to the current browsers.
The main security goal of Sound-Proof is to defeat a remote attacker, who has learned the user’s password (e.g., by hacking into a password database server of the web service in question), and is attempting to login to the user’s account, and possibly multiple user accounts. As argued in SoundProof, given the prominence of remote attacks on the web today, this is a very legitimate goal. In order to login to the user’s account, the remote attacker against SoundProof would have to predict the ambient sounds in the environment of the phone and possibly be in a very similar environment as the user, which may be a difficult endeavor in practice, as shown in the security analysis of SoundProof. In other words, if the attacker cannot predict the user’s environment and is in a different environment than the user, the audio samples at the browser’s end and the phone’s end would not correlate, thereby preventing the attacker from logging in. Indeed, in the comprehensive security evaluation, Sound-Proof was shown to be highly secure against such remote attackers. In addition, in the usability evaluation reported, Sound-Proof was shown to be highly user friendly, when contrasted with a traditional 2FA scheme involving OTPs. Given these very promising security and usability properties, Sound-Proof is apparently now under early deployment phases in the form of a start-up (see: http://sound-proof.ch/).
In this study, we identify a weakness of the Sound-Proof system, namely, the remote attacker does not have to predict the ambient sounds near the phone as assumed in the Sound-Proof paper, but rather can deliberately make—or wait for—the phone to produce predictable or previously known sounds (e.g., ringer, notification or alarm sounds). Exploiting this weakness, we build Sound-Danger, a full attack system that can successfully compromise the security of Sound-Proof. The attack involves buzzing the victim user’s phone, or waiting for the phone to buzz, and feeding the corresponding sounds at the browser to login on behalf of the user. The attack works precisely under Sound-Proof’s threat model. The flow of the attack is as shown in the figure below:

Sound-Danger Attack Flowchart: The attacker (human or bot) enforces the ambient audio to be highly similar at both (attacker’s and victim’s) ends by making calls or sending notifications to the victim’s phone, or waiting for an alarm to go off at the victim’s phone, and by simultaneously feeding the same sounds at its own end. The attacker would succeed in logging into the webservice, while the user may remain unaware of the attack or even when the attack is detected, the account may already have been compromised.

Sound-Danger Attack Flowchart: The attacker (human or bot) enforces the ambient audio to be highly similar at both (attacker’s and victim’s) ends by making calls or sending notifications to the victim’s phone, or waiting for an alarm to go off at the victim’s phone, and by simultaneously feeding the same sounds at its own end. The attacker would succeed in logging into the webservice, while the user may remain unaware of the attack or even when the attack is detected, the account may already have been compromised.

People

Faculty

Student

Publication