Email and Reusable Token URLs

I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.

While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state开发者_运维技巧, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.

In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.

So the question is, does anyone know of an alternative way to hide a token in such an email?

I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.

You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.

That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.

It'd also be counter-intuitive for users.

This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.

Another answer, perhaps more useful:

Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that: https://wiki.mozilla.org/Browser_History:Redirects

For example, in Chrome, if you navigate directly to

amazon.com

it will follow a 301 Redirect to

www.amazon.com

If you then check your browser history, it will only show

www.amazon.com

Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.

(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)