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)
Passwordless login done right
41–50 of 56 posts
Re: Passwordless login done right
#42> 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 biom…
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)
Re: Passwordless login done right
#43The 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…
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.
Re: Passwordless login done right
#44> 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.
Re: Passwordless login done right
#45I'm intrigued! But a few questions/comments: * 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 -…
* 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 syst…
> 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
Re: Passwordless login done right
#46Earlier quoted context omitted.
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…
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?
Re: Passwordless login done right
#47Users understand the Username/Password workflow. 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. No…
Couldn't agree more.
Brings to mind the "unlocking a car door with a smartphone app" story that I read via HN a while ago
Re: Passwordless login done right
#48> 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…
Thanks for the feedback. A few answers:
"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.
Re: Passwordless login done right
#49> 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 biom…
I suspect some people have started to assume that "two-factor authentication" literally just means "phone/dongle".
The very fact that they claim that makes me uncomfortable with their knowledge of security.
Re: Passwordless login done right
#50Earlier quoted context omitted.
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)