
The Noise Around You Could Strengthen Your Passwords - ersiees
http://www.wired.com/2015/08/noise-around-strengthen-passwords/
======
drblast
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.

~~~
Kenji
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._

~~~
drblast
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.

~~~
nathancahill
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

~~~
_kst_
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.

~~~
bcg1
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

------
craigds
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.

~~~
droopyEyelids
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

------
rburhum
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.

------
david_shaw
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.

------
PythonicAlpha
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.

------
kazinator
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.

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

~~~
slg
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.

~~~
ikeboy
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).

~~~
slg
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.

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

~~~
slg
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.

~~~
ikeboy
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.

~~~
slg
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.

~~~
ikeboy
>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).

------
norea-armozel
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.

------
kazinator
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.]

~~~
Niten
> 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.

------
GrinningFool
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.

------
stephengillie
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.

------
arturadib
"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.

------
jotm
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...

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

