HN Explorer

Ask HN: Unique URL authentication

7 points by dublinclontarf ↗ HN
I read a post not long ago how posterous only requires you to send an email(with the users first post) to create an account.

I admired the simplicity (from the users perspective) and pondered the ways we could just stop asking people for information and just use our apps.

And I believe, for a great many apps, the bare minimum you need is an email.

Which brings me to my question, why bother asking the user to login, why not email them a unique, random, url (a https one of course) that once clicked authenticates them. The idea being that only the user would have access to it(or anyone with access to that email account).

Stupid idea? Any obvious holes I'm missing?

18 comments

[ 4.7 ms ] story [ 54.3 ms ] thread
jorangreef
Cool idea. It will require the user to have access to their mail right then and there, i.e. maybe they're on a public machine and don't use GMail. Another thing you could do is skip the registration altogether. Let the user into your app using a single big button on the home page. Then, once they've interacted with your app, progressively ask them for the vital info you need. You walk the wire for a few minutes where a user could leave without registering, but I'm sure the upside in conversion rate would be worth it. I've just (literally yesterday) launched a different kind of contact management app at https://szpil.com that has an experiment going with this (one-click button, deferred registration).
jorangreef
Another idea I'm mulling over is using a person's real name for signing in together with their password to provide enough entropy, then enforcing that the password be long enough etc. so that the name/password combination gives you something unique enough to authenticate with. The reasoning behind this being that typing your real name in is somehow more personal, more gratifying and more memorable than typing a username/email. Another slant on this is that people have more than one email address which the authentication mechanism could take into account. The final idea is allowing any of: real name/email(s)/id as a username. Although name is great for interface use, id/email are better for programmatic use.
dublinclontarf
I was planning to do this anyway, as the user goes through the app, get a nibble of information each time. But with only using an email, it instantly creates an account for them.

Sending a login link also gives them something to keep. And if they come back years later(after just using) it should be easy for them to re-authenticate.

dotBen
This is something OKCupid do in their emails. They have "Log in instantly" with a url that contains a unique hash.

Even if you are not into dating, do check their site out... They actually have all sorts of nice stuff on their site - their labs section and blog are also very interesting if you like stats and data/analysis.

ErrantX
A few sites do do this. The one that springsto mind is okcupid - if you click a link in their mails it logs you in.
imp
I don't think it has any holes, but it could be inconvenient if they clear their cookies or want to use your site from a different computer. Instead of remembering one of their standard passwords, they have to dig through their email to find the link you sent them just to use your site.
dublinclontarf
Well I'm not getting rid of standard passwords, just that it wont ask for any during registration, and the user can continue to use without until such a time as they want to set it. At least, making it more optional.
ydant
This is a growing trend, and I love it. The concept is "lazy registration", and it makes perfect sense.

I think most sign-up forms are designed out of fear - fear of spammers and fear of people quitting the software. Forcing a user to fill out pages and pages of info isn't going to make them more loyal to your site, it just annoys them. It also won't stop spammers - they are just as creative as you are.

So let the user use your site (perhaps flagging changes such as comments as pending) but send them a link to authorize their site. Once they've done that, their changes go live and they can fill in the info you need of them. By doing an action (such as commenting), they have proven they are interested and they are much more likely to want to finish the registration process.

Edit: On second read-through, I see you might be talking about replacing a login with a URL permanently. I don't like this idea as much as it's a lot easier for me to remember my username/password than I am a unique URL (that's complex enough to not be easily guessable). If you don't want to manage the login process, use an openID provider (and Facebook connect, Google Login, etc).

dublinclontarf
No no no, not replacing the login, just defering it.
ydant
Ok, based on the other responses, it seems this line confused more than just me:

Which brings me to my question, why bother asking the user to login, why not email them a unique, random, url (a https one of course) that once clicked authenticates them. The idea being that only the user would have access to it(or anyone with access to that email account).

JunkDNA
One issue I can think of is that this exposes your users to email phishing attacks by training them to click a URL in an email. I know Facebook has had this effect on me. I have come close to clicking on phishing URLs because I get so many legit Facebook emails with links that I let my guard down.
tptacek
It's fine until you want credit card numbers.

* Your password is never stored in a list of bookmarks

* Your password isn't permanently stored in email

* Those password-change random URLs that get mailed to you expire

* Your password is never logged in standard server logs

* Your password isn't a part of your browser history

patio11
And, from the user's perspective,

* Your password isn't 45 characters of ancient Aramaic. (Why hello, OpenID.)

keefe
Well, it is not really secure if someone could find a way to poll the address space of your random URLs, which (without much thought) does not seem difficult.
adn37
Usually we do this for one time authentication only.
yetanotherjosh
A pro/con discussion would need a more detailed explanation of how exactly you plan to implement this.

That said, some general advantages to having a permanent user-chosen password include:

- The user can login on any client even if they don't have access to their email on that device. In order to accomplish this without a user password, the user has to have their email device and the secondary device present at the same time, and you'd need to give the user a human readable OTP (one time password) they can enter into the secondary device manually.

- Convenience. Users doesn't have to visit their email to click an URL and can instead proceed directly to the logged in experience.

- Are you planning to give users a "log out" link, and then expect them to do the email hurdle each time? That additional email hurdle will encourage users to stay logged in when they might otherwise logout, which could make their accounts more vulnerable to theft. However, if you expect and want users to remain logged in for longer periods of time, it becomes more justifiable.

- For various reasons email delivery can be significantly delayed. It's not as much a problem now as it was in the past, but this lends email usage towards more asynchronous tasks where timing isn't terribly important.

- If you use a good password, it's more secure than email authentication. Remember that emails are basically the digital equivalent of post cards. But if you use bad passwords, like most users do, all bets are off, your accounts (email account included) are highly vulnerable to theft in any case.

- The URLs in emails will need to be designed so that they are only good for one use and time out after an hour. Otherwise gaining access to the email history or browser history becomes a means to steal login state. However, this also applies to the URL authentication that goes on typically in "forgot password?" workflows, so you probably have to do this work anyway.

- Users are sometimes reluctant to enter a valid email address for privacy and spam concerns. Often they will put in a garbage address just to get past that part of the sign up hurdle.

I'm sure there's more to say. That's what I can think of at the moment.

android2
It's really hard to get perfect email deliverabiliy. God help any of your users who have Yahoo or Hotmail. There are no major flaws assuming you properly timestamp and sign your urls. But between email latency, deliverability, etc, not to mention how alien the experience will be to most people, I'm not sure if I would advise pursuing the system as a primary one.
justlikethis
Logout of HN. Click 'add comment'. Use the 'create account' boxes instead of the 'login boxes' to create a new account. Done.

What's wrong with that approach? It's as easy or easier than using email, which I may or may not be logged in to.