RSS Feed

The Design of Software (CLOSED)

Step 1: You enter your email address.
Step 2: You click on a link in the email.
Step 3: You're logged in.
Step 4: To log in again, bookmark the link and go to it, look up the email or have it resent.

Et voila - no username or password required. Discuss.

Er... I know it's insecure, but for most webapps it doesn't matter that much.

Depends on what you are hiding I guess. If it is for a free newsletter subscription, no problem. If you intend to store user info that the users don't want to expose to the rest of the world based solely on an e-mail address, then no!

So you are giving them a transferrable tracking cookie? Why?

I guess the link would hold a random string to identify the user? I certainly don't hope that the raw or hashed email would be in the string.

Actually this gives me an interesting thought. Who invented the username/password login sequence and why? Where can we learn about the basic basics of user authentication?

That's how craigslist does it for their ads. Though they associate a unique URL with your ad on craigslist rather than to identify you as user. I think it's okie for all trivial web applications.

Username/password is just the "something only you know" form of authentication. You can consider it just one string of characters, where the username part guarantees uniqueness within the namespace.

> So you are giving them a transferrable tracking
> cookie? Why?

No, just a randomly generated URL which either loads a cookie or doesn't.

By verifying the existence of an email address you are delegating the authentication onto the email server. Your authentication is at best, as strong as the email authentication.

This method cannot be used as an authorization method.

I meant cookie as in some token, not in the sense of a HTTP cookie.

What exactly are you hoping too mitigate/achieve?

Cookie as in "you forward your email to a different address and you still have a valid logon". For example:

1) create a bugmenot152342@hotmail.com account
2) get your logon
3) forward the email to an email address you actually use.
4) logon as many times you want.
5) never use the bugmenot152342@hotmail.com again.

The term for this in .Net is Passport Authentication - ie you create a MS passport and the website devolves responsibility to the (equivalent of) the email server, as said above. I've not found this useful as almost all of my sites are intranet based.

1) What happens when you need the website but don't have the url and can't access your email? (eg behind corporate firewall)

2) What happens when someone forwards an email "check out this great site" and the user credential is propogated to many others?

>Dino: This method cannot be used as an authorization method.
No, it can't, but that's not what its for.

FWIW, I still think the best method is username/password (with the email address as username, if you like).

1) Login validates user/password against DB
    a) Encrypt password and retrieve matching record
    b) Test stuff (e.g. account locked)
    c) Update user record with GUID
    d) Store GUID in local session cookie
2) Every other page (that you care about)
    a) Validates post domain
    b) Validates GUID against user record
    c) Return from b) gives authorisation data
    d) Update timeout on session cookie
    e) Page content dependent on c)

1a) Encrypt to match previously encrypted password. You are doing this, right?

Justin, this isn't .NET passport.

One thing in here I really like, Colm - password _and_ username are duplication of data, so s single ID would be ok. You can furter manage authentcation data trough cookies, have no-email version (just a link, that is presented on a page, think ab "password recovery" link etc...

I mean - I totally agree with you, that username:pasword pair of values is artificial amd can be substituted for a single value.

It isn't secure of course and that doesn't seem to be your aim but an extension would be the 'authenticate my desire to be on this page'  whereby you click the link which has your email attached to it, you get a new email with a new authentication/login link.

It might irritate the pants off the users though.

This is as least as secure as username/password combinations without SSL, surely?

I would think that it is secure enough for e-commerce sites.

> This is as least as secure as username/password combinations without SSL, surely?

Except for the part where I can change my password if I want/need (not that I ever do), and that my credentials are stored in my favorites list instead of in my head.

And stop calling me Shirley!

Users spend 99% of their time surfing other web sites than your own. The username password sequence is well known, why change the user's habit ? It is counter productive.

Each time I log on Amazon.com, I spend 30 seconds staring at the login screen, wondering where to enter my password, which button to click to NOT register again.

Geniuses at Amazon probably went through a similar brainstorming, I already know the result: wasted time for the users.