Question

In implementing my site (a Rails site if it makes any difference), one of my design priorities is to relieve the user of the need to create yet another username and password while still providing useful per-user functionality.

The way I am planning to do this is:

1. User enters information on the site. Information is associated with the user via server-side session.
2. User completes entering information, server sends an access URL via e-mail to the user roughly in the form of: http://siteurl/<user identifier>/<signature: HMAC(secret + salt + user identifier)>
3. User clicks URL, site looks up user ID and salt and computes the HMAC with the server-stored secret and authenticates if the computed HMAC and signature match.

My question is: is this a reasonably secure way to accomplish what I’m looking to do? Are there common attacks that would render it useless? Is there a compelling reason to abandon my desire to avoid a username/password? Is there a must-read book or article on the subject?

Note that I’m not dealing with credit card numbers or anything exceedingly private, but I would still like to keep the information reasonably secure.

Answer 1

One word (well, actually two) – Referer header.
The next site your user goes to after visiting yours will see his credentials in this header. Moreover, the user will not be able to change his credentials after they have been compromised that way.

The idea of username/password authentication is that it involves two separate pieces of information – a known user id and an unknown password that can be freely changed on per-user basis. In your system (apart from the Referer thing), there is one single password for all – the “secret.” I also suspect it will be reasonably easy to bruteforce the signature (since I know my user id) and recover the secret, rendering the whole system useless.