I'm intrigued! But a few questions/comments:<p>* How is this two-factor? I only see one factor (a thing you have, your phone). Email adresses are not secret.<p>* 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.<p>* 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?<p>* 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.)<p>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.
> Basically, this is an extremely secure, 2 form factor, idiot proof login system<p>As far as I know, factors are<p>1. Something you know (password)<p>2. Something you have (a dongle or phone)<p>3. Something you are (iris or fingerprint)<p>With <i>only</i> pressing a button on a phone, how can this be two-factor? There is no password ("passwords are obsolete" and usernames are <i>not</i> a knowledge factor in multi auth) and nothing of biometrics. Am I missing something?<p>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.<p>[1]: <a href="https://passwordless.net/" rel="nofollow">https://passwordless.net/</a>
This method isn't secure unless both the website and phone display a code (e.g. a short hash over a Diffie-Hellman, or other, shared secret and the session id) so you can determine which session you're authenticating. Otherwise, anyone who can determine that you're logging in (traffic analysis is possible even if it's encrypted) can initiate a timing attack.<p>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.
The article starts with the words "Imagine you want to try the service offered by a site, but you have to log in to be able to do it." That's a problem statement, and the solution is clear: Let users try your service without forcing them to log in. That's it. It's that simple: Offer a demo. No third-party two-factor-authentication-by-people-who-don't-understand-what-two-factor-means stuff needed.<p>Once you have people hooked, they <i>will</i> gladly open an account if they intend to return.
I thought this would be a write-up on SQRL <a href="https://www.grc.com/sqrl/sqrl.htm" rel="nofollow">https://www.grc.com/sqrl/sqrl.htm</a> that uses QR codes and a secure identity database on your phone to authenticate you. Unlike the article, SQRL is an open protocol that can be developed and used by anyone. It is in alpha stages but I have used a prototype and it works really well.
It's not two-factor. Your phone becomes an access card. Which is cool because you don't have to remember a password. But it's not two-factor.
Users understand the Username/Password workflow.<p>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"<p>I think devs should instead focus their efforts on making that standard Username/Password flow work as effortlessly as possible.
> Well, the above scenario is not science fiction anymore.<p>Proceeds to describe something that is not the above scenario.<p>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.<p>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.<p>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?<p>The "Passwords are obsolete" mantra is built around one assumption:<p>"Specifically, the ability to send an email or SMS to users reliably and quickly."<p>And the problem with that assumption is that it's wrong. Wrong, wrong, wrong. 100% wrong. Relying on a system like this <i>will</i> cause problems for your users, and it will be impossible to fix with software.
First of all, thanks for all the great feedback. We’ve just launched in beta and we are striving to make UNLOQ the simplest authentication system. We know that we have a long way ahead of us so we appreciate all the feedback. Here’re a few answers to the comments I’ve seen above:
1. We believe it is a two factor: something you have = your phone; something you are = you’re fingerprint (for the phones that comes with this option and it is enabled); something you know = you’re PIN (you can set additional PIN’s on your profile).
2. Regular two factor provides you with a code to insert in the browser after you authenticated with username and password. We make use of two channels in order to authenticate a user: the browser used to provide the identity and the service’s server - UNLOQ server - device to provide proof of identity. We believe that this makes the system harder to break through man-in-the-middle type of attacks.
3. We know we still have to work on user experience, but entering just your email and then approving on the phone the request seems easier than entering the full set of credentials followed by another security code (as 2fa proposes)
I fail to see the 2 form factor but here's something I found inside the documentation an application can request the last 3 digits of a user phone number + valid email to allow a successful login.<p><a href="http://unloq.readme.io/v1/docs/authenticate" rel="nofollow">http://unloq.readme.io/v1/docs/authenticate</a><p>DIGITS_REQUIRED<p>Please provide the last 3 digits of your profile's phone number. (Only when application has its authentication type set to email and digits
> Think Fort Knox like. We use the same algorithms approved for top secret information like AES 256, SHA3 and public-private key encryption.<p>statements like this make me very very nervous as AES by itself is basically useless and the impotent part being <i>how</i> they use AES.
Being a bit paranoid, how do I know you won't login as any of my users without their permission? Or in other words, if your systems get compromised, how can I be sure that my system won't get unauthorised logins?
I like how "extremely secure, 2 form factor, idiot proof login system" is bold and "once the user has the unloq app installed and configured" is not.
<a href="https://unloq.io/#/" rel="nofollow">https://unloq.io/#/</a><p>It's Free!<p>(up to 10,000 users)<p>And what happens then? What does it cost?