Can my web application log in and remain stateless?

Question

We have a web application that is stateless. We use http authentication through SSL / TLS. User browsers presumably save authentication credentials (perhaps even after disabling the browser if they configure their browsers like this). We check them with every access.

For reasons mainly related to usability, we would like to stop using HTTP authentication. Is there a reasonable way to enter a username and

• Stay stateless.
• It does not require users to re-enter credentials at every access.
• Be at least as secure as HTTP authentication over SSL / TLS.

For example, we are prepared to use cookies and may store username and password as a cookie. However, this seems less secure. But is it? If we use a volatile cookie, is it less secure than any method the browser uses to store credentials for a session duration or longer?

We could save the username and password hash, as suggested here: What do I need to store in cookies for the “Remember Me” implementation during user login , but is this better?

We could store a random token as a cookie, but then we need to save the lookup table (session) on the server and become state-safe.

We could store the encrypted version of the credentials as a cookie, and then decrypt and verify each access. This one seems like it is a bit more secure than http authentication, and also does not require state. However, I’m not sure that we need additional decryption overhead. And is it safer? If someone gets a copy of an encrypted (or hashed, as above) string, does it give the same access as if they had a password?

I would be grateful for your thoughts, but let me start with the assumption that HTTP authentication via SSL / TLS is secure enough for our purposes, and we want to remain stateless.

EDIT

After some further research, I think this stackoverflow question: client-side sessions speaks more accurately about the problem, and the answers are correspondingly better. Thank you all for your input.

Answer 1

In a closed system, it is preferable to use corporate intranets or just a regular site, but with a small, reasonably savvy crowd), confirming the SSL certificate. Issue a certificate for each user, let them install it in their browsers, and you can revoke access to this certificate at any time (see, for example, the ssl-cert authentication system myopenid.com (unfortunately, atm buggies).

This will require some work with part of your users, and if this is not possible / desirable, a cookie token will be much preferable, and if you look at the user / passwd command or cookie token, you should not make that much difference.

Answer 2

You can look at PHP sessions as an alternative to cookies.

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

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

This does not take into account HOW you should authenticate users first. This is usually done by searching for the stored hash usernames / passwords in the database.

Answer 3

I do not see a random token as more or less stateless than a username and password.

Both must be scanned in some form of database. Your application already had a status. Authentication or authentication status.

The username and password that were sent were exactly the same as the random token.

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