Simple Universal Authentication System

This idea is perhaps stupid. Nevertheless, I rather document it here for good than not documenting it at all.

Here is the story. I had to reset the credentials of an online account I have. As usual, I went on the vendors' site, clicked the forgotten password feature, typed my email address and clicked "submit". A moment later an email arrived in my inbox with instructions how to reset the password. Additionally, inside the email there was a link with a token which I had to click on in order to perform the necessary actions required to reset my account.

I am so used to this routine that I no longer think when performing it. It takes me virtually 20 seconds to get my account back.

It is not a secret that once an attacker has access to an inbox, s/he can easily obtain access to other sites/applications the victim has registered with the compromised email. However, what if we turn this well know principle to solve a quite rudimentary and very old problem - authenticating on the Web.

Let me explain. Technically speaking your inbox is an universal authentication system. Mail and HTTP are so tight nowadays that they cannot function normally without each other. We use SMTP to reset forgotten password credentials, which basically works like this: we receive a one-time password (in the form of a link with a token), which we use to create a username/password pair. Alright then. Instead of going through the a middle man (your username/password pair) why don't we use the password reset mechanism to authenticate with the any web enabled system?

It will work like this. First, when you signup you just type your email address, nothing more. You receive an email with a link to login. You login and you do your thing then you log out. At some point in the future you decide to come back to the system. You type your email address again and you receive another link in your inbox to login.

Limitations and Security Implications

I started this post by saying that this is merely an idea and I wont recommend it to anyone at this stage, although if implemented correctly, the solution may actually work. There are many things that needs to be considered. First, tokens have to be expired once they are used. Second, we need some kind of self-destruct feature in order to prevent authentication spam. 3rd, it wont be obvious when one of your accounts is compromised. Today, if one of your accounts is compromised via password reset you can detect that something wrong is going on due to the fact that you cannot login normally anymore. However, this only have implications in the long term.

Some Benefits on the Top of my Head

Well, it is trivial to implement very strong authentication systems on the top of this framework. PKI is what comes to mind. Imagine the following. When the application authenticates with you, you receive the message encrypted with your public key. The only way to read it is to have your private key at hand and this is much better way of authenticating then using simplistic and prone to failure username/password-based authentication mechanisms.

Some Words About Accessibility

Obviously, this approach is not very convenient. However, the process can be abstracted to the extend where the user doesn't have to do or know anything. Of course, security might be an issue.

There you have it.

Archived Comments

Nathan

The only issue I see, is the fact that most people don't like to log out every time they use a site. Say I use this to log into Ebay, later when I go to check my auction, I wouldn't want to have to go through this system again. Also after winning the auction I go to PayPal to pay, now I have to do this all over again because its a new site. This is a feature of OpenID that I like so well. One thing I do like, is the ability to use my own email. For security I could set up a private email which only I have access to, through second factor authentication, but this could work with OpenID also.

Geoffrey Lee

In concept, this sounds very similar to OpenID.

Ben

The majority of the world's mail traffic is unencrypted and easily sniffed, whereas SSL connections are less likely to be sniffed (although still possible in some situations).

pqs

Mugshot.org already uses this system. Or at least, they used it the last time I logged in the system. I wrote a post about it last year http://bits.quintanasegui.com/arxius/2007/04/05/login-without-a-password/

FilipM

Belgium implemented the Electronic Identity Card (eID). Every eID has a chip on it and a PIN-code to activate it. The personal data is also stored on the chip (picture, address, etc...) so they don't need a new card when they move to a new address, they just change the data on the chip. Although there were some bugs and security problems in it at the beginning, they think now it's secure. The interesting part of this? It's used for various implementations outside federal public services, some companies use it for their employees to login every morning, car-rental company's use it to register someone, it's used as a badge to open gates, etc, etc... But more and more websites are using it to be sure that the visitor actually is the person they say they are (for example the tax-on-web website from the Belgium governement). The current problems for authenticating on the web with eID are: Not everybody has a card-reader (yet) and it will only work for belgium citizens. Perhaps this wil be the new way of authenticating in the future if everybody has an eID-card and reader? Or will it just open a new branch of security-issues? What about "Big Brother is watching"? Will there be any annonimity possible on the web? What do you guys think of this system ?(seriously promoted by microsoft by the way)

pdp

FilipM, Natwest (RBS) have a similar security mechanism, although they just use it to verify the user's authority when performing critical transactions such as transferring funds, etc. It is secure, no doubt about that. However, the problem is the annoyance of keeping the reader with you all the time. And if you loose it then you are locked out. You cannot reset your credentials! It could take months before they send you a new reader. Therefore the system is kind of flawed. It is similar to the situation where a vendor implements account lockout feature and then the attackers go ahead and lock everybody out of the system. This is an administrative DoS and you don't need a botnet to make the attack work. Now, regarding the auth system I proposed. Well, it sucks in many ways. But it does provide a universal logon.

Beau

I like the idea of using text messaging for two-factor authentication. The idea would be that when you go to log into a website, you get a text message with a unique code that's valid for say 5 minutes. This will also alert you that someone is attempting to access your account. I see potential applications for this in banking, VPN, online gaming, or anyone who wants a cheap true two-factor authentication. Now which way to the USPTO?

singu

One problem with this on top of my mind - we are used to e-mails to be received after few seconds, however SMTP doesn't guarantee how much time it will take to deliver the mail. It's perfectly possible for a server to get an error and then just sit and wait for couple of hours before retrying. During that time the user won't be able to log-in, or worse - will spam itself with login attempts. Also - large number of logins will surely put a domain into couple of spam black-lists.

romee

as singu mentioned, smtp is not interactive. on top of it, I've found greylisting a very effective way against spam, but it has drawback of delays, which can be in hours. however, i've found http://www.xmppid.net/ and imilar services very usable, which uses xmpp instead of smtp.

V

I thought about this on banking websites. They should offer their clients a mechanism to send the password in a short message to the clients cellphone. Costs per short message are low and the medium is a completely different one (no IP network).

w0lf

Good thought but you never know how many loop holes are hidden beneath!!! :)

Nik

Interesting idea. There are also some products around that use SMS messages to provide one-time passwords on the basis that pretty much everyone has a mobile, and carries it with them. Not perfect (DOS is a potential issue, and GSM is by no means perfectly secure) but good enough for many applications.

V

I also thought about a kind of "personal recognition" to implement aside the passwords. Let's say - after your first logon you upload a picture of something special - your girlfriend, your child, your car. This picture can be used to assure that you really are the person which is owner of this account. How? Well - let's say that the banking website prints a picture wall after the password login. A page of 30 pictures, or 50, or even 10. Pictures contain cars, pets, people, toys and one of them something you have uploaded before. (file names have to be randomized - sure) This would be something an attacker would only know if he has evaluated things in your social life as well. This would often be much more difficult than breaking CAPTCHAs or intercepting Firefox-Password-Manager.

ioo

I wrote and use such system for authentication to my antispam service (and aghhh, I've seen it in a competitive product). Works like a charm, I also give users possibility to use a traditional username/password authentication, but apparently nobody uses it anymore.