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.