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: What should I store in cookies to implement "Remember me" during user login 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: Client side sessions states the problem much better, and the answers are correspondingly better as well. Thanks to all for your input.

Answer 1

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.