
Passwordless login done right - anaolykarpov
http://programming.tudorconstantin.com/2015/05/passwordless-login-done-right.html
======
olemartinorg
I'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 - 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.

~~~
snupa
* 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

~~~
olemartinorg
* 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?

------
juriansluiman
> 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.

[1]: [https://passwordless.net/](https://passwordless.net/)

~~~
mfoy_
I suspect some people have started to assume that "two-factor authentication"
literally just means "phone/dongle".

~~~
jackreichert
The very fact that they claim that makes me uncomfortable with their knowledge
of security.

------
nly
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.

~~~
snupa
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)

~~~
nly
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.

~~~
nly
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.

------
tom_mellior
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.

~~~
nly
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.

------
jrasmussen0
I thought this would be a write-up on SQRL
[https://www.grc.com/sqrl/sqrl.htm](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.

~~~
nly
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)

~~~
cm2187
But do you know any system that can eliminate a MITM attack?

------
daigoba66
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.

------
fixxer
The fact that this made it to the front page is concerning.

------
glaberficken
Users 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.

~~~
sageabilly
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.

~~~
glaberficken
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

------
jasonlotito
> 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.

~~~
mpatachi
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.

~~~
jasonlotito
> We do offer the option to create additional profiles on others email a user
> might have.

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.

------
mpatachi
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)

~~~
MacsHeadroom
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](http://www.google.com/patents/US20110219230)

~~~
devinegan
It looks like that patent had a final rejection in 2013.
[http://portal.uspto.gov/pair/PublicPair](http://portal.uspto.gov/pair/PublicPair)
(13/039,209)

------
Globz
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.

[http://unloq.readme.io/v1/docs/authenticate](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

------
anExcitedBeast
This isn't multifactor. Use an actual multifactor solution, like Google
Authenticator or password+SMS.

------
cwmma
> Think Fort Knox like. We use the same algorithms approved for top secret
> information like AES 256, SHA3 and public-private key encryption.

statements like this make me very very nervous as AES by itself is basically
useless and the impotent part being _how_ they use AES.

------
shark234
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?

------
korijn
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.

------
buro9
[https://unloq.io/#/](https://unloq.io/#/)

It's Free!

(up to 10,000 users)

And what happens then? What does it cost?

------
struct
Cool idea, how is re-authentication handled beyond the initial sign up? Do you
get a text message each time?

~~~
millsuk
Push notification to your phone. They don't have iOS support yet which counts
me out from trying it out.

~~~
namochan
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.

~~~
snupa
I'm curious, what device/android version do you have?

------
esusatyo
What happens when you lose the phone?

~~~
millsuk
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.

