Passwordless authentication

Is authentication via username and password more secure than a passwordless one? In the majority of the cases, probably not.

This may be shocking, and thing is: passwordless authentication is easier from a user experience point of view!

But what is passwordless? Well, like the name suggests, it is an authentication system which doesn't require the user to input any password at all. Not even logging into Facebook or Google, still without loosing any security layer. But how's it possible? Well, I thought about various possible protocol drafts. The one I think may be deployed to a live system/website is the one I'm going to describe.

Before starting, let's talk a little bit about browser fingerprinting: it is the technique which allows the server to get a unique* fingerprint of your browser and operating system (*well mostly, it varies from implementation to implementation. More information). This means that if a server tracks the fingerprint, it may allow a user to register simply entering the website. Slow down, not that simple! Fingerprinting is based on numerous factors, like display color depth, browser plugins, language and other variables. So if you change any of them, the fingerprint changes.

So fingerprint is good, but not perfect: it won't allow an indefinite login time, nor would allow multiple browsers or computers to login to the same account; also anonymous modes or nets may filter this data. So what? Well, add little less randomness to the system! What about if the user only has to input his/her email? Every time the system doesn't recognise the pair email/fingerprint, an email will be sent with a link containing a confirmation token to enable the single fingerprint to login. More or less what happens with Valve's Steam system. And block those TOR users once and for all. At least to browse on your trusted website.

What about privacy? You for sure don't want to give an untrusted server all the data required to create the fingerprint. Well, it's all done client-side, for example via JavaScript. No user is interested in sharing his own fingerprint, so it shouldn't be sensitive to library hacks. The only problem may be a MITM attack, but this is common to all the non-secured HTTP sessions (using SSL resolves the problem).

You may argue that without a password, the system is intrinsic less secure. It is, wait, it's not... Actually most of the users use the same password for all the authentications that don't require a change on a regular basis: find the one and you'll have access to lots of the user's services. Also, all the common authentication mechanisms need an email used in case of forgotten password. The hacker only needs to find out the email's password, rather than the single service's one. See? In the end the "extra" security layer about having an authentication based on passwords is, in the majority of the cases, only a bait and switch.

Passwordless authentication may even be more secure! It's common practice, as described above, to store user emails in the databases. But can the user really trust the server's security? I do not. Passwordless authentication based on email and fingerprint doesn't need to store emails in clear text. You can simply hash them using a random seed (saved in a configuration file). You don't need to know the email! If the user needs a new token, the email is provided by the input directly! You only need to compare a hashed string with another, that's all.

Final thoughts

There are pros and cons about using this kind of authentication. Just like there are pros and cons using the actual password-based kind.



- 19th September 2013

> back