No-login user authentication
June 17th, 2008I am making some portal. It is a sort of the portal where people will need to register and fill in some info. They have to have an option to login at any later date and modify their info but this will not be like everyday or even every month thing. It seems stupid to me that people have to create and remember a new username/password for every utility that they need limited access to very rarely then.
So I am making some variant of user authentication system for them that doesn’t use usernames or password. The point is that it’s much more minimal to make and use than the standard hog of stuff you have to do to make a usable user authentication system.
So what elements does normal system need:
- verification email with a link and functionality to accept verification
- login (username/password) form and functionality
- forgot password link, form and functionality
- change password form and functionality
- logout link
This no-login system is basically like a one-time-password system where it is not limited to one-time, because it would be impractical and it has no reason to be.
So how does it work: When you register to the web-app you receive an email. In it there is a link, you click it and you are “logined” into the web-app. When you need that web-app user area again you open the email and click it again (or you bookmark it, or whatever). But you can delete (loose) the email at any time and when you need access again you go to web-app and fill in your email into “get me a new key” form and you receive another link on email that you can use as long as you want and then delete too (if you want).
So what elements does this system need:
- sending out email with the link - 80% the same for the first time (registration) and for all “get me new key” times
- “get me new key” form and functionality
- logout link
you don’t need verification via email - because the email with the key link is also a verification of their email
you don’t need login form and functionality - obviously
you don’t need forgot password link, form and functionality - because you are meant to forget it and you use “get me new key” anyway
you don’t need change password form and functionality - because there is no password
So it has some pluses, but I will see how it performs in real. If you see any weaknesses go ahead and tell me!
June 18th, 2008 at 10:34 am
well, one weakness is that this is not exactly secure, is it? Anybody can log in using that permanent login link.
June 18th, 2008 at 11:13 am
the link with a key is not more permanent than username and password in a classic login are.
If you think someone got to your link you can “get me a new key”, just like you can can change the password if you think someone got to it in classic auth.
The only weak spot is that you get link/key with an email and you will probably have it stored somewhere versus that password can be stored in your head only.
But the truth is that you get username/password on email at a lot of webapps too, and even if you don’t most people probably use “Save my password” functionality of their browsers for most of webapps which result in a same consequence (paswords can be seen by anyone with access to their browser, like if you made a bookmark to the admin app with key in it.).
But I agree, because it’s not made with an option to have password stored only in your head it’s not something I would use at any app where foreign access to the users area would have more critical consequences. But in reality I think it’s not even a slice less secure than any of webapps that I use and have choosen “Remember my password” in the browser or have password stored in some email that I got from them.
June 20th, 2008 at 11:26 am
I still think it’s a very unsecure system and I personaly would not use it. It has many drawbacks:
1. So the only connection between app and me is my e-mail? What if I change e-mail? I gues all data is lost then.
2. Link generation… Based on what algorithm? Easy to crack?
3. What if I request a new link for someone else? Then his connection is lost I gues…
4. What if I don’t have access to a registered e-mail at the momment? No way to login then? This is a serious disadvantage.
This are just a few things that come to my mind atm., but would probably get many more…
June 22nd, 2008 at 7:05 pm
hi Gorky
2. link has a 16 character random key (far longer than usual passwords if you want to brute-force find them). The key holds no data and is random and there is not (theoretic at least) way to crack a random key, so I think no worries here.
3. This is the same as “Forgot password” (enter email and submit) at websites with usual usr/pwd authentication where your password gets reset to some random string and mailed to the email that you gave. If someone else enters your email you get a new password/link to your email. Not the best feature but used at a lot of classic auth systems too.
4. You can always store the link to your desktop or to bookmarks or in extreme case print it on paper. Mail is just the delivery mechanism.
1. I will answer 1. at last because I think that yes this is worse to a degree than at classic auth systems.
At classic systems if you forget a password AND loose the access to the email you signed up (for example domain expired) you are f*cked a little. Because you can’t do “Forgot my password” any more.
Here you a f*cked a little if you loose access to the email already (and don’t have the link stored anywhere else) which is probably more likely to happen than above situation.
This made me avare that I have to do another form “Change your email” form must be here (as it must be in classical system) and I will add it. This is worse in my case but it’s not a deal-breaker for me.
And it’s not a security concern (in view that unauthorized person will gain access to you data) but contrary makes it extra secure then as NOBODY (even you) won’t get to your data then
—
Thanks for debating flaws of this with me, you are welcome to think out more or bounce my responses.
June 23rd, 2008 at 9:56 pm
4. You said it right. Mail is just a delivery mechanism. But let’s face it, in your app, mail is more than a delivery mechanism - it’s a main login thing. Why would I wrote down or store somewhere a “16 character random key”?! It’s a whole lot easier to remember or even write down user/pass info. And that’s not a “not-big” thing… People use public computers and mobile devices all the time to access the internet. And you give us two conditions (web+e-mail) instead of only one (web). And link/16c storing is not the solution…
June 25th, 2008 at 10:49 am
yes, I agree this is a negative feature of the concept and I would not use this system everywhere by any chance.
I would consider using it only in cases like I described in the blog post: “They have to have an option to login at any later date and modify their info but this will not be like everyday or even every month thing”
In this case, having to remeber a password that you use only every 2 months is also a negative point to me.
I implemented this and it works and I will use it at this portal I am making right now. But I will see, if it doesn’t show it’s worth using I will go to a classical system. I am not a fanatic you know, just trying out new operators