* How is this two-factor? I only see one factor (a thing you have, your phone). Email adresses are not secret.
* Again, email adresses are not secret. How do you limit login-spamming? I don't want to wake up in the middle of the night because someone is trying to break into my account.
* What about timing attacks? If i stand over your shoulder while you're in the library - and i try to log in using your email address a few seconds before/after you, wouldn't you think "oh, probably a fluke" and allow my login? How would you differentiate between logins?
* If you're not that security-minded, you could have a desktop client as well - so you don't have to rely on your phone. At that point you could probably just have a browser plugin that does it all for you. (And at this point you're pretty close to what i already do with LastPass, although the site i'm visiting doesn't have to do anything special other that implementing a regular username/password login system.)
EDIT: Also, as far as i can see from the Play Store screenshots, the app only asks you "Do you want to log in at <site>?". A far better solution would be to show the user a number sequence (or a cute cat or dog picture) on both the login page and the phone. If those two mismatch, the login attempt is not from your session.
* So what if the attacker started a login request a few milliseconds before i did? How can i differentiate between the attackers login attempt and mine?
sounds like an easy DoS vector if the person knows your phone number as well
As far as I know, factors are
1. Something you know (password)
2. Something you have (a dongle or phone)
3. Something you are (iris or fingerprint)
With only pressing a button on a phone, how can this be two-factor? There is no password ("passwords are obsolete" and usernames are not a knowledge factor in multi auth) and nothing of biometrics. Am I missing something?
By the way, not entering passwords is a fantastic way to login. I have been using the Passwordless [1] method for some time and it works great.
I've also only glanced over the API docs, but it looks like the app just provides a secret to the server with each authentication request. So this is still essentially password authentication, you're just relying on your phone being more secure than a potentially key-logged terminal.
In relation to the phone, users may pin-protect (for now, we're looking into additional methods) each individual profile. The main difference is that the user no longer uses the same communication channel (browser-server) to send the full set of credentials, with UNLOQ, a separate channel is used (device-UNLOQ paired connection)
If you do that, enforce TLS/SSL, and display a session code to stop timing attacks (even if you only allow one login at a time, it's still vulnerable to race), then it's not terrible.
Every attempt I've seen at improving this fails by introducing some new unexpected workflow complexity such as "sign in with google, fb etc" or "use your phone"
I think devs should instead focus their efforts on making that standard Username/Password flow work as effortlessly as possible.
Good UX involves taking away steps and streamlining flow, and until flow is streamlined and easier than the previous process users won't accept it.
Proceeds to describe something that is not the above scenario.
Secondly, this ignores the reality that phones in the hands of real users are not a reliable means of identification. People lose or change their phones all the time.
Next, this creates a massive road block for users in trying to sign up. As it stands now, unloq limits itself to a single email for a single user.
This also ties your authentication to a third party service. What assurances does unloq provide should they go the way of seemingly every other startup these days? What happens when Google buys them?
The "Passwords are obsolete" mantra is built around one assumption:
"Specifically, the ability to send an email or SMS to users reliably and quickly."
And the problem with that assumption is that it's wrong. Wrong, wrong, wrong. 100% wrong. Relying on a system like this will cause problems for your users, and it will be impossible to fix with software.
"As it stands now, unloq limits itself to a single email for a single user." -> We do offer the option to create additional profiles on others email a user might have.
"that phones in the hands of real users are not a reliable means of identification" -> We do agree that phones by themselves are not secure enough. Currently we do offer the option to add a secondary PIN on each profile, but we are thinking to enforce it to the application level.
I looked at the API, and it didn't offer that feature.
> Currently we do offer the option to add a secondary PIN on each profile, but we are thinking to enforce it to the application level.
So a password.
By the way, the founders of Duo Security hold the patent on completing an authentication from a smartphone. Something to keep in mind. http://www.google.com/patents/US20110219230
Once you have people hooked, they will gladly open an account if they intend to return.
http://unloq.readme.io/v1/docs/authenticate
DIGITS_REQUIRED
Please provide the last 3 digits of your profile's phone number. (Only when application has its authentication type set to email and digits
statements like this make me very very nervous as AES by itself is basically useless and the impotent part being how they use AES.
