You can easily deactivate it. Would I use this for sensitive data? probably not as I use a password vault, but for non sensitive sites this looks like quite a slick approach.
I have quite a few android devices, but the play store tells me that "This app is incompatible with all of your devices". But I'll keep an eye on this, seems nice. I guess it's two-factor enough, because I have a password on my phone.
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.
Meeting users where their understanding is now and not trying to drag them along to where their understanding should be is definitely a challenge with replacing traditional workflows (like username/password, swiping a credit card, letting the waiter carry your card off for swiping, etc). The issue I see with this is that it's introducing another step into the process instead of removing a step or making it easier. Now, instead of just remembering a username/password combo, you have to 1) remember a username 2) Remember that the website that you're visiting has the option to use unloq.io (because they're probably going to offer both unloq.io and the standard username/password) 3) enter in username 4) find your phone 5) unlock your phone 6) wait for confirmation on your phone 7) hit allow 8) look up, reorient yourself to your monitor and mouse, and continue.
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.
* 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.
* Once you create an application, you can set how you want your users to provide their identity. You can ask just for the email, email+digits or just their phone number. However, when you deny a notification from your phone, the user is required to provide the second identifier (email requires additional last 3 digits, phone number also requires email, and email+digits requires the full number in addition)
* The system only allows a single login per user, so if you have initiated the request first, somebody else would have to wait for you to finish the request until they can initiate it). There are additional limitations happening in the background that prevents spammy logins to reach the user's phone.
* We're still trying to improve our UX, so we might take that in consideration for future releases
* So if i deny the login attempt on my phone, an attacker who knows my phone number can still log in to my account? Email + phone number is not two factors, it's zero (neither is a secret).
* 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?
> The system only allows a single login per user, so if you have initiated the request first, somebody else would have to wait for you to finish the request until they can initiate it
sounds like an easy DoS vector if the person knows your phone number as well
So two factor would be "something you know" (password) and "something you have" (phone) - and this just has the latter. So it's single factor but with a different single factor than the passwords we are all used to.
Good point, you don't. But on the other hand, filtering out an email you don't want is easy (in most email clients), so you won't get a notification each time. I'm assuming this app has no filtering, so if someone wanted to DOS me with this, they could - there's no way i could (or would) handle a ton of login requests per second to try to find the login request i initiated. You can't DOS someone with account signups or the "forgot password" functionality, as they could still log in to whatever service they need (while their mailbox fills up).
The app actually has a firewall, preventing DOS attacks on the user. The main rule is that only one authentication request can be active per user, so the user will always receive ONE push request at a time.
Also, when you create an app, you can specify the number of authentication requests you expect, coming from your app. You can (currently) set it from 1 to 25 requests / second. So if somebody would try and DOS you, UNLOQ will limit and filter these requests.
But i still wouldnt know which request was genuine. Even worse. The genuine request might be filtered out! By doing this you make the DoS more effective actually.
I have never found a good solution to the trade-off of protection against brute-force vs availability.
If I disallow X requests per second then I might enable DOS attacks on a user.
What if a cluster of zombie machines around the world is attempting to log in as a politician to gmail at their publicly known address? How would the politician ever get in, if login attempts are rate limited?
the rate limit can be per username/per ip address/per time period (you receive one notification once every 10 minutes), or a combination.
Yes, when you have a botnet of a few thousands computers you could DoS someone. But with that in hand you can also DoS every web service on the internet (with a few exceptions)
> Basically, this is an extremely secure, 2 form factor, idiot proof login system
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.
yes, currently the app has an optional pin unlock that you can set per profile. However, we're looking to add additional "something you know"'s on the user's part to minimize unauthorized access to the device.
This definition of multi-factor is a bit of a myth. All of those 3 things are something you 'know' in the sense that they all boil down to secret keys. Your dongle or phone stores a key. Your fingerprint and iris can be copied (scanned and stored digitally)
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.
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.
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 system has some built-in rules that prevent timing attacks from happening, so that only one authentication request may be active per user. A few other rules run in the background, preventing other similar attacks.
In relation to the communication between the service server and our server, we're currently offering the traditional api key/secret method, but we will roll out RSA-enabled calls.
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 use a PIN, make sure you encrypt the API secret with the PIN and do NOT store a hash or any other means by which to verify that the PIN is correct. I'd also suggest an (UNencrypted) secret device token such that you can actually detect when an app install is being used with a bad (incorrectly decrypted) API key and disable it after N attempts. This will prevent people abusing this policy for DoS against regular friendly usernames.
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.
You should also add an API for session management, so I can always see what sessions are active under my account and kick them out if they look suspicious.
I thought this would be a write-up on SQRL https://www.grc.com/sqrl/sqrl.htm 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 also has other merits. It is stateless (so all you need is to save the master key offline). And it doesn't rely on a third party (so no one else that you and the website you log in to knows about your relationship).
SQRL is worse in many respects. While it uses public key cryptography, which helps in the MITM scenario, it suffers from only weakly addressing the complexities of spoof protection (A malicious site, or a trustworthy but compromised site, can display a QR code for a different website or session). UNLOQ avoids some of this because it relies on direct notifications from the server to your phone (hopefully over TLS, which makes MITM unlikely)
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?
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.
Once you have people hooked, they will gladly open an account if they intend to return.
Exactly. You can always create a demo session with a long-lasting cookie, and then associate it with a new users account when they eventually do register.
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)
Even if it is two-factor, for the reasons you described, it's all over a single channel. There is no out of band mechanism- meaning this can easily be MITM'd. UNLOQ is poor authentication security in more ways than one.
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
> Well, the above scenario is not science fiction anymore.
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.
55 comments
[ 3.3 ms ] story [ 125 ms ] threadEvery 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.
* 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
If I disallow X requests per second then I might enable DOS attacks on a user.
What if a cluster of zombie machines around the world is attempting to log in as a politician to gmail at their publicly known address? How would the politician ever get in, if login attempts are rate limited?
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.
[1]: https://passwordless.net/
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
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.
statements like this make me very very nervous as AES by itself is basically useless and the impotent part being how they use AES.
It's Free!
(up to 10,000 users)
And what happens then? What does it cost?
Once you have people hooked, they will gladly open an account if they intend to return.
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
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.