A technical look on building a democracy

No-Password authentication

Passwords are troublesome. I can tell they’re troublesome because most website have the “Lost your password?” button readily available. Because password tends to be lost, or forgotten, or entered via keyboard with different layout (Try using the “£” symbol and good luck to all american-keyboards users).

Passwords are crackable, as majority of people don’t understand the likelihood of someone trying to break down their password. So to make the life of hackers slightly more difficult we now have the CAPTCHA mechanism, that aside from being already cracked by hackers is simply annoying. In fact, the “Lost your password?” is annoying too – you might as well call it “Annoyed? Click here”. Think of it this way – the user clicking this button is only one step away from not using the service.

And funny enough – this button is actually the solution to our problem. When you click button a two-steps authentication is initiated – usually via email which includes an unbreakable code that allows to update your password. Well, why just change password? Why shouldn’t it allow access to all the service?

With this reasoning, once you can you edit the password – the service is practically accessible and should therefore be so!

So instead of asking the user for his username (which is usually an email anyhow) and password – why not simply asking for the email?

So here’s the entire procedure

user open service, type in his email, click submit

A special token with time of creation and the user’s IP is created and sent to the user’s email

User click the link in his email

Token is sent back to the server and is verified that the IP matches and token hasn’t yet expired (let’s say one hour from token creation time)

A new token is created with user-id and user’s IP and sent to the user, encrypted

The user cannot decrypt this token but whenever he communicate with the server he passes this token along to authenticate himself

The browser should keep the authentication token for a reasonable time – let’s say 3-6 months, during which the user won’t have to go through this process again. This cookie should not and cannot be simply copied to another machine as it require the computer to have the same IP. And if you’re truly concerned with security, the service can ask the user for his public PGP key along with his mail and thus send him an encrypted mail only he can decrypt.

The only problem with the mechanism that I found is that it requires your user to temporarily leave the service and check his email. How many users will you loose because they forgot to return and how many will you loose because the password was just another hassle they didn’t care to handle?