The Noise Around You Could Strengthen Your Passwords | Hacker News Reader

The Noise Around You Could Strengthen Your Passwords

wired.com

63 pointsersiees42 comments

So you let a third party record whatever you're doing for a few seconds for security purposes?!

Oh, my.

Edit: before you shout "but it's just a signature!" Think of a large entity with huge resources that goes ahead and creates signatures of an entire catalog of recorded English conversations. Now you upload your signature, and that entity can reconstruct your conversation via a catalog search.

I reacted like this too. But read the article carefully:

To protect your privacy, the app doesn’t upload the audio itself, just the digital signature.

Yeah, I get it, but think of the things you can do with that digital signature.

Joe and Bob - were they together on Sunday at 2pm? Well let's check the digital audio signatures to see if they match.

Or, John just uploaded a signature that matches our samples of "Kill the president."

And a few thousand other examples.

It depends on the signature.

On the "probably too simple, but..." side, record 8 seconds of audio. Normalize it. Bucket the net volume audio levels across quarter-second intervals. Fuzzy match a bit. If the levels have some change in them, and the changes match, you're in. Virtually no useful information in that signature.

By contrast, if you get "clever", and want to go with that basic approach, but you want more bits to fuzzy match, so you break apart the frequency bands into 64 bands and sample on 50 millisecond intervals, and you're getting perilously close to revealing speech in the signature with enough processing. (You lose a lot, but you end up with more to work with than we privacy sensitive folks would like.)

The point isn't that either of these are what they are doing. I don't expect either of those would "work" on their own; I kept them simple to describe and simple to understand for the purposes of this post. The point is the info leak on the signature can vary quite widely depending on how they do it, and without knowing the algorithm you can't speculate very effectively. It could be anything from "fairly safe" to "you might as well just send up the audio".

Not feasible. Digital signatures are a one way operation, like hashes:

Let's say the audio signature of "Kill the president" is 9a0c0a6868a2a784059d9a634e4a58c0.

"kill the president" in a different tone would be entirely different: ed3e3cd6be6eeb2de9b480e2c9590cc9

The server has to compare the signature of the sound recorded by your computer to the signature of the sound recorded by your phone. The sounds will not be identical, so the signature comparison has to be able to detect whether two sound recordings are sufficiently similar. It can't use, for example, SHA1 hashes for this purpose.

Couldn't they ignore noise below a certain threshold and create the signature just based off of the "peaks" and "troughs" so they could expect an exact match, and/or hash several samples from the recording in case some portions don't produce an exact match? Seems like there should be a way to this without revealing information about the recorded sound

If a slightly different sound resulted in an entirely different signature, the system would be useless for comparing recordings of ambient noise, which will never be identical. You've taken the analogy with hashing too far.

Eh, these are bound to be more like Shazam guess-that-tune signatures, with behavior wildly more loose than any cryptographic hash like an MD5.

Conside that the web browser's desktop/laptop microphone and the cellphone/telephone microphone will probably never produce identical audio samples, if not due to the actual transducers, then simply due to proximity to various ambient audio sources like the user's breathing versus fan motors attached to a laptop shell or desktop case.

So you're saying they'll have to have a database of these hashes to match against?

The solution to these problems is simple.

1. "Joe and Bob - were they together on Sunday at 2pm?"

Joe and Bob avoid this by not authenticating using the same mechanism in the same room at the same time.

2. "John just uploaded a signature that matches our samples of 'Kill the president'".

Solution 1: John understands how the authentication works by recording ambient sound, and refrains from saying things like "kill the president" during that procedure.

Solution 2: John starts an Internet meme which encourages every user of this authentication mechanism to say "Kill the president" over and over again during the procedure. Now, millions of signatures match.

Most people do not consider the consequences of technology nor how to route their behavior around them.

People can be told that the authentication method listens to their ambient sounds through their phone and PC at the same time to determine that those two pieces of equipment are in the same location, and that although their privacy is safe-guarded, they shouldn't say anything confidential during this time.

That is a fair point. Especially considering that the recording can be started from the outside by a 3rd party.

because you're shouting "kill the president" when you're logging into a website?

Regardless of what is actually uploaded, a phone app and website implementing this would need to get microphone permissions from the user, and it would be difficult for the user to verify that raw audio isn't being captured as well. (There's no separate "audio fingerprint" permission.) That could become a barrier to adoption in practice.

I'm also not sure how I feel about a second factor that would allow an adversary to authenticate by simply sitting in the same coffee shop as me. Manual authentication seems important, and U2F already addresses some of the nusiances of TOTP-based schemes.

This is a really clever innovation, though.

Well... that third-party already something valuable of you. Your email, bank account, whatever is behind that auth.

So, do you trust a third party having that information of you?

They already have some information, so you might as well give them more information?

Substitute money for information, and I would love to do business with you.

"You are already paying me $20, so you might as well give me $100."

This is honestly one of the few really good and creative ideas I've seen here in a VERY long time.

I really don't mind sharing an audio hash with someone that already has my full banking information/history in there. Not only that, I would be EAGER to do it if that will increase the security of the current contract that I have with them, specially since they found a way to do it that it's not bothersome at all.

But yeah, whatever you say naggy HNers.

I applaud the attempt, but this sounds much more annoying than regular 2FA. If it doesn't work, you'll have no idea why.

With regular 2FA it didn't work because you typoed the code, and it's easy to fix that.

Personally I don't find 2FA annoying at all. Most sites just have long-lived cookies so you only have to do 2FA on a new computer, or once every few months.

AWS is the exception which requires you to 2FA every time you login, which is definitely annoying. They should fix that.

It gets a lot better once you have a smart watch. Not for everyone, I know, but if you're entering two factor codes all day like I am, it's not too much of a compromise

I realize that certain intelligence agencies already have the ability to remotely turn on various sensors on my phone, but to enable a more generic version of this...Hell no. I'd rather take the "hassle" of entering the code by hand.

This seems like a more error-prone 2FA. Yeah, you don't need to type in a few numbers; instead, you take your phone out and hope that the ambient noise is "close-enough."

Of course, if you're in a particularly erratic environment -- such as songs switching, or sitting in a crowded area -- I'm sure the security mechanism would fail.

Seems frustrating and gimmicky, but maybe that's just me.

An app on my smartphone can be activated remotely without my noticing and record the sounds of the surroundings?

Sounds like a new attack vector for me (e.g. when somebody can manipulate the app or replace it by a fake version -- even "smart" apps can have errors) and even when it is not, the possible security win, it might bring, sounds rather small to me.

The main problem, I see, is that this "two factor" authentication gives a wrong feeling of security -- and the users might think, that a secure password is not so important --> think, the old 4digit PIN-code is "OK".

As an attacker, I would simply try a silent room and a time where most people are asleep. When somebody has forgotten to deactivate his phone, I got him.

In general, I distrust any security measure that relies on the possession of my phone. To bundle many security related things on one single thing, is a bad idea. Even with central keys of houses, there are so many problems, but what currently happens is, that the smartphone becomes the key to my home, my bank, my car ... (not kidding, a lock with smartphone access is already sold).

When I loose my phone, I am lost ...

There was a (rather old) film "Filofax" about somebody that found the filofax of another person an practically took over his live. Maybe it is time for a film called "smartphone". We are living in "smarter" times.

Here is another idea based on audio, which doesn't require any aspect of audio to be sent to the network.

1. The phone is equipped with a public/private key.

2. Authentication begins when the client side of the application running on the PC or other device ("authenticating device" or AD) receives a message from the network informing it of the phone's public key, and a challenge token. The AD's goal is to obtain a signed version of that same token from the phone.

3. The phone also receives a message containing the token. A handler on the phone recognizes the message and kicks into action. It retrieves the private key, signs the token, and emits audio representing the signature.

4. The authentication module on AD is listening for this audio, and decodes it. Then it uses the public key to verify the signature against the token. If the signature matches, it declares to the application that the phone is present in the room.

Simpler version, without cumbersome crypto:

1. The phone and AD receive a numeric code.

2. The phone converts the numeric code to a short sequence of musical tones. These are played out the speaker.

3. The AD hears the tones and recognizes the correct numeric code, declaring the phone to be present.

The downside is that the phone makes noise, which may not be acceptable in some circumstances. This can be mitigated by using a simple audio cable with 1/8" plugs from the phone's headset to the mic input on the PC.

Why not just make some sound with one and have the other pick it up?

That might be easier to intercept. If you are simply recording sound, an attacker doesn't know the exact moment that the recording is starting or ending. If the system is generating sound, the trigger is easier to pick up.

But if you hear your phone making noise and you didn't just sign in, you can stop it (just have an "it wasn't me" button in the app).

The problem is when you are in a coffee shop, someone notices you are logging in to Facebook, and now your phone broadcasts the login sound to the browser on both of your laptops. Suddenly two factor authentication is one factor again. It reduces the requirement from having physical access to your phone to having proximity to your phone.

But that's the same if you listen as well. Either way, they need your password and proximity.

Not really because the timing is a secret. If the sound is broadcast you know "I should start attacking now". It is a trigger to tell you something important is happening. If you are simply recording, it is passive. You can't tell that someone is trying to log in at that exact moment with a sound signature starting at 2:51:05 PM and running to 2:51:08 PM.

First of all, if two people log in at once, the system knows something's wrong. Second, how is your attack more likely to succeed from the passive attack? In yours, I know you're connecting to Facebook, I log in and use your sound. Without a broadcast sound, you're not connecting to Facebook at all, I'm just next to you. It seems to me that you'd need strictly more things to go right in the broadcast sound attack.

Whatever you have then, you can use to succeed in the regular attack. Where is the narrowing of the threat model?

The only thing I can think of is that the actual information of a log in is leaked, without it being exploitable because they don't have your password. This doesn't seem very useful by itself especially considering that they won't know which site you're logging into.

Think of it like a traditional two factor authentication except instead of the key being sent discreetly to your phone it is broadcast to everyone around you. They now all have the chance to use that broadcast code in an attempt to login before you.

I don't think it's a problem for the average user in the average login scenario. However, it still doesn't mean it isn't a security concern.

>They now all have the chance to use that broadcast code in an attempt to login before you.

As I said above, by that time, it's too late, because the server should detect multiple logins and disable the code (and hopefully alert you that someone has your password).

I don't think this is a good idea since many of the noises that surround the average person is fairly non-random. Be it the hum of a car engine or even static of a white noise generator. There's too much structure in the machines and living things around people. Plus, atmospheric changes can change or offset noises in such a way that most people don't notice but it would throw off any sufficiently sensitive hardware which would be harder still to verify against.

Although this is good, all it saves is typing a few digits and checking a box "[ ] let's not do this again on this particular computer".

Other hardware solutions could be found. For instance, an app on the phone could receive a security token string, and use bluetooth to send it to the PC. Or, a QR code (or bar code) could be sent to the phone which pops up on the screen. This is held up to the PC's web cam which scans it. [Insert your idea below.]

> Or, a QR code (or bar code) could be sent to the phone which pops up on the screen. This is held up to the PC's web cam which scans it.

The opposite of this (bar code on computer is scanned by the phone) is roughly the user experience of SQRL.

Just require users to recite "my voice is my password" after receiving an audible notification to indicate that the computer and mobile devices are listening.

This is an interesting idea, even with flaws. It's almost like taking a fingerprint of the audio in the space around you. It also reminds me of the "voice-passwords" from old James Bond movies.

"You don’t need to unlock your phone or even take it out of your pocket or purse, as the recording is triggered automatically by the server"

Would Apple ever let an app do this? No, probably not.

Or how about, get this, we use a simple program that generates a password that would take 500 years to be cracked? The only hassle is couple more clicks to insert that password...

I'm guessing this is not an iPhone app? Because iPhone doesn't let apps do that.

Reply on news.ycombinator.com