The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Website authentication

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.
Colm O'Connor Send private email
Wednesday, July 27, 2005
 
 
Er... I know it's insecure, but for most webapps it doesn't matter that much.
Colm O'Connor Send private email
Wednesday, July 27, 2005
 
 
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!
dil.b.ert
Wednesday, July 27, 2005
 
 
So you are giving them a transferrable tracking cookie? Why?
Just me (Sir to you) Send private email
Wednesday, July 27, 2005
 
 
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?
Peter Monsson Send private email
Wednesday, July 27, 2005
 
 
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.
JD Send private email
Wednesday, July 27, 2005
 
 
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.
Just me (Sir to you) Send private email
Wednesday, July 27, 2005
 
 
> So you are giving them a transferrable tracking
> cookie? Why?

No, just a randomly generated URL which either loads a cookie or doesn't.
Colm O'Connor Send private email
Wednesday, July 27, 2005
 
 
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.
Dino Send private email
Wednesday, July 27, 2005
 
 
I meant cookie as in some token, not in the sense of a HTTP cookie.

What exactly are you hoping too mitigate/achieve?
Just me (Sir to you) Send private email
Wednesday, July 27, 2005
 
 
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.
Dino Send private email
Wednesday, July 27, 2005
 
 
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 Send private email
Thursday, July 28, 2005
 
 
Justin, this isn't .NET passport.
Colm O'Connor Send private email
Thursday, July 28, 2005
 
 
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.
accidently drunk Send private email
Thursday, July 28, 2005
 
 
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.
Simon Lucy Send private email
Friday, July 29, 2005
 
 
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.
Colm O'Connor Send private email
Friday, July 29, 2005
 
 
> 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!
Jonas Grumby Send private email
Friday, July 29, 2005
 
 
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.
Thierry Send private email
Wednesday, August 10, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz