Google acquires SlickLogin: dogs go wild!
SlickLogin, an Israeli start-up, is behind the technology that allows websites to verify a user's identity by using sound waves. It works by playing a uniquely generated, nearly-silent sound through your computer speakers, which is picked up by an app on your smartphone. The app analyses the sound and sends a signal back to confirm your identity.
The firm confirmed the acquisition on its website but did not provide any financial details of the deal.
Too bad they don't still put whistles inside packages of Cap'n Crunch cereal!
(Score: 5, Insightful) by everdred on Tuesday February 18 2014, @01:23AM
Or another one nearby?
(Score: 2, Insightful) by KibiByte on Tuesday February 18 2014, @01:25AM
That was my exact same thought. But then again, physical presence is always the greatest security threat.
The One True Unit UID
(Score: 1) by efernsler on Tuesday February 18 2014, @01:26AM
Exactly. One wonders what 'nearby' means to the audio signal. 1'? 5"?
(Score: 5, Insightful) by Nerdfest on Tuesday February 18 2014, @01:30AM
If I were to do something like this, the server would encrypt a random number with the public key of the client. The client would decrypt, and send it back encrypted with the public key of the server. If the numbers matched, you get authenticated. I'm not a cryptography or authentication expert, but I'm pretty sure that would work without any problem with eavesdropping. I'm really hoping they didn't get a patent on this ...
(Score: 2, Insightful) by everdred on Tuesday February 18 2014, @01:40AM
Ah, so the phone would have to have been already authenticated; this is just checking to see if the known phone is present?
I imagined the idea behind this tech was to easily pair devices.
(Score: 2, Funny) by Nerdfest on Tuesday February 18 2014, @02:07AM
Following a fine tradition, I didn't read TFA, am studying for a beer exam (yes, really), and came up with this in less than 10 seconds. It seems to me to be a great way to do a key exchange based authentication, but it was admittedly a very quick effort that may be flawed.
(Score: 2, Funny) by Gaaark on Tuesday February 18 2014, @03:46AM
Is that an oral exam?
Me hop(p)ing so! :)
Stout fellow, you! (Now where's that Porter with my beer?)
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 1) by Qzukk on Tuesday February 18 2014, @02:35AM
That seems to be the point of it: to authenticate using the proximity of your phone to the computer's speakers. Since the computer and the phone would need to communicate (either directly or indirectly) for the computer to know that the phone had received the signal and OK'd it, I'd expect this to be the second factor in 2FA (so the computer already knows which phone it should expect confirmation from).
Nifty, but it's basically just saving 6 keystrokes for Google Authenticator.
(Score: 2, Informative) by edIII on Tuesday February 18 2014, @10:15PM
That's really no different of an authentication scheme than one that just goes through the Internet. Authentication is performed because the smartphone decrypted a payload to send back. That smartphone still needed to be secured through other means.
What this is really more like is out-of-band key exchange.
Website sends random number in plain-text. Smartphone detects random number. Smartphone applies agreed upon mixing procedure (probably traditional crypto) and sends back through communications medium that is different than website-device being authenticated.
An eavesdropper would need to present in all 3 mediums, as well as the attacker. Website-Internet, Physical Environment, Smartphone-Internet.
Out-of-band is not a new concept either. Google already has a patent on another form of out-of-band key exchange.
Technically, lunchtime is at any moment. It's just a wave function.