Archived - Hasn't been maintained in 6 years
#Introduction This is an example application using residence based authentication on iOS for the iPhone. Residence based authentication is an alternative to password based authentication. A related public talk was given at NSConference by qnoid in Leicester on Wednesday, 06 March 2013.
A video of the above implementation also available.
Tom Adriaenssen has created:
An iOS library , called IIResidenceStore.
A javascript client, called ResidenceStoreClient.js.
A .NET server, called NResidenceStore.
#Problem
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>By using a password, you actually give up security control and risk your users' data. Stop asking for one now. http://t.co/JUuLMcENBu
— Markos Charatzas (@qnoid) February 22, 2014
#Motivation
- To provide a secure alternative to the password given existing user behavior (i.e. not logging out) and practices (i.e. forgot password link via email, long lived sessions)
- To provide a simple way for users to login.
- To provide a simple way for developers to implement user authentication without relying to third party services (e.g. openid, oauth)
#Implementation Upon registering, the user's client - in this case the iPhone - is assigned a residence. Once the residence is authorised, the user can use that residence to login. The residence has no expiry date but can be deleted by the user on demand to prevent further access from that client.
An example server implementation is deployed on heroku which uses email verification for the residence. The source code is available on github. The email merely allows the user to verify a residence. A high level overview of the client/server implementation) is also available.
#Other work on user authentication Marco Arment, @marcoarment has "implemented a crazy passwordless login system" for The Magazine on the web. Haven't come across any written public posts by Marco with details on the implementation. It appears that no token (e.g. a password or a residence) is used for user authorisation. The user is asked for his email and a link is sent, with an expiry date. The link is effectively an authorised login that sets a cookie for the client.
Ben Brown, @xoxco tweeted "(we) implement passwordless login in all new software as a rule" and also written a post on passwordless login and an aftermath on his hacker news post.
Wired (November 2012) wrote an article on passwords and identity theft.
Arstechnica ( 2009) wrote "30 years of failure: the username/password combination".
#Considerations
- There is a chance that the user loses access to both his email and any client with an authorised residence. How does the user regain access to her data?
- Email is not really designed for user verification. Might worth considering a protocol for user verification.
#Discussion There is a Google+ topic already on the subject, so please focus your efforts there.