Can My Web App Implement User Login and Remain Stateless?

Question

We have a web application that is stateless. We are using http authentication over SSL/TLS. The user's browsers are presumably storing authentication credentials (possibly even after a browser shut-down if they configure their browsers that way.) We validate them on every access.

For reasons mostly having to do with usability, we would like to stop using http authentication. Is there a reasonable way to implement user login and

• Remain stateless.
• Not require users to re-type credentials on every access.
• Be at least as secure as http authentication over SSL/TLS.

For example, we are willing to use cookies, and could store the username and password as a cookie. However, this seems less secure. But is it? If we use a non-persistent cookie, is it less secure than whatever method a browser uses to store credentials for the duration of the session, or longer?

We could store username and a hash of the password as suggested here: http://stackoverflow.com/questions/1858448/ but is that better?

We could store a random token as a cookie, but then we have to keep a lookup table (session) on the server and become stateful.

We could store an encrypted version of the credentials as a cookie and then decrypt and validate on every access. This seems like it is slightly more secure than http authentication and also does not require state. However, I'm not sure we want the additional overhead of decryption. And is it really more secure? If someone gets a copy of the encrypted (or hashed, as above) string, doesn't that give them the same access as if they had the password?

I'd appreciate your thoughts, but let's start with the assumption that http authentication over SSL/TLS is secure enough for our purposes and we want to stay stateless.

EDIT

After some more research, I think this stackoverflow question: http://stackoverflow.com/questions/2131522/client-side-sessions states the problem much better, and the answers are correspondingly better as well. Thanks to all for your input.

Answer 1

I don't see a random token as being more or less stateless than a username and password.

Both need to be looked up in some form of database. Your application already had state. The state of being authenticated or not authenticated.

The username and password that was being sent was exactly the same as a random token.

So my answer to your question is No. A web application cannot implement any form of user authentication and remain stateless.

Answer 2

You may want to look into PHP sessions as an alternative to cookies.

You can start a session with a single call to session_start().

From there you can store whatever data you want about the user with the global $_SESSION array.

This doesn't take into account HOW you will authenticate users in the first place. That is usually done by looking up stored usernames / password hashes in a database.

Answer 3

In a closed system (company intranets, or just a normal site but with a small, decently savvy crowd) validating by SSL-certificate would be preferable. Issue a certificate for every user, let them install it in their browsers, and you can revoke access for that certificate at any time (see for instance the ssl-cert identification system of myopenid.com(unfortunately buggy a.t.m.).

It would require some work on your users' part, and if that is not possible / desirable, a cookie-token would be far preferable, and whether you look up a user/passwd combo or a cookie token shouldn't make that much of a difference.