avoid hitting DB to authenticate a user on EVERY request in stateless web app architecture?

Question

Summary

Once a user logs into a web site and his username/password credentials are verified and an active session is established, is it possible to avoid hitting the DB for each and every request from that user? What is the recommended method of securely authenticating subsequent requests for the life of the session, while minimizing DB queries and other internal network traffic?

Background

In a stateless web app server architecture, where each request has no knowledge of any prior activity from the user, it would be necessary to query the DB on each and every request from that user (typically by querying the session ID stored in a cookie and transferred in the request header). But what if some basic information was encrypted and stored in that Session cookie that had enough information to validate the user for non-sensitive, non-editable requests? For such requests, you could as an example encrypt and store the user ID and something that uniquely identifies his machine as much as possible (user-agent + ip address) in the Session data. The key used to encrypt the data could change daily making it difficult for any hacker to clone the Session data on a different machine. When the Session expires you would need to fully validate the user's credentials. The fact is, the biggest threat to hacking a user's session would be someone using a user's computer that he or she left unattended. Should I just not worry about this and let some level of caching between the web app servers and the DB take care of expediting the authentication process? While it may seem to be unnecessary optimization, it seems like a candidate ripe for improvements in efficiency since each and every request requires this process. Thanks for any suggestions!

Answer 1

Yes it is possible, and this technique is widely used.

It does have some minor drawbacks compared to stateful sessions:

1. It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires.
2. The use of a server-side secret to create the tokens creates a single point of failure: if the secret is captured, an attacker can impersonate any user.

Deciding whether to use stateless or stateful sessions depends on your performance and security requirements. Online banking would tend of use stateful sessions, while a busy blog would tend to use stateless sessions.

A few tweaks are required to your proposed scheme:

1. Encrypting the token does not protect it from tampering. You want to use a Message Authentication Code (MAC) which does protect tampering. You may additionally want to use encryption, but that is less important.
2. You need to include a timestamp in the token and put a time limit on their validity. Somewhere around 15 minutes is sensible. Normally you would automatically re-issue shortly before the timeout, and usually the reissue would incur a database hit (although even that can be avoided)
3. Do not include the user's IP address in the token. Approximately 3% of users will legitimately change IP address during a web session, due to modem resets, changing WiFi hot spots, load balanced proxies and more. While you can include the user agent in the token, it is not normal to do that - consider it an advanced technique to use if you are sure you know what you're doing.
4. If an attacker captures a session cookie they can impersonate that user. There is nothing you can really do about. Instead, put all your effort into preventing an attacker capturing the cookie in the first place. Use SSL, use the "secure" cookie flag, fix all cross-site scripting flaws, etc. And have some user advice to lock their screen when their computer is unattended.

I hope this is helpful to you. If anything is unclear or you need further information, leave a comment and I will see if I can help you further.

Answer 2

Generically, it is possible to "store" state information on the client, even sensitive information such as authentication data; such storage is used to save resources on the server, e.g. to minimize database load. See these previous questions:

• Is it possible to have authentication without state
• Demystifying Web Authentication (Stateless Session Cookies)
• Is my session-less authentication system secure?

In a nutshell, whenever you want to store some information s on the server, to be looked up if the same client comes back, you can instead send it as a cookie to the client. You may want encryption because that information might be "private", in the sense that you do not want to show it to the client himself. You probably want integrity because you do not want the client to be able to alter the data without your consent. So you want both encryption and a MAC, or, better yet, one of these nifty encryption modes which do both properly (GCM being the often quoted standard for that).

As generically, when you store state information on the client and the client, then you lose some control over the life cycle of that information. The client may elect not to send back the cookie, i.e. simulating a new, fresh client; also, the client may send back an old cookie value. Whether this is a problem for you depends on your exact situation. You will probably want to include in the cookie data a time stamp, allowing you to recognize cookie values which are really too old.

Answer 3

There are some ways to achieve this problem (and I have seen this approach used in REST APIs).

1. Using HTTPs to authenticate and then use the stateless API.
2. Using a basic HTTP authentication method and use an expiring tokenID in each request.

In any way, if you need authentication and stateless you will need manage the authentication in your app session. After verifying the credentials you can actually make the database query without authoring it again via trusted user or similar.

Be sure not to allow direct connection to the database from any other user than the one you have allowed to do so after the credentials check.

Answer 4

I am sure that you understand that to omit an authentication based on a previous authentication makes your web application a session application. Isn’t it a session state been authenticated? Know that you are studding to have a session; you may ask yourself why you required a session lees application. Normally people want session lees applications for two main reasons: Requests can be delivered to different servers without worrying of any dependency between client and any member of a server farm. Memory linkage when a large number of users are accessing concurrently. Even on session applications you can meet those requirements by making the server to issue an encrypted signed token when the authentication so other members of the web farm can verify that token to have an idea that the user might be legitimate. Impersonation is still possible because following request need the same token. You can include in the token data from request http headers and IPs to restrict its use but middle proxies can still use the token by doing NAT and copying the client headers. Then only way to make invulnerable to man in the middle attacks is by protecting the authentication request by https and letting the client send you with the credentials a random generated key that will be used to decrypt the signature of the request, the client in each request will encrypt some data of the request as a signature. The data encrypted can be the session ID and a sequence element from a pre-establish sequencer generator. Do not use the simple incremented by one because of its predicable behavior. As in each request this signature is different from previous signatures, you can be sure that client is authenticated. If sequencer generator it always incrementing you can cache the last element used to make a simple check previous to a full check; broadcasting other members of the farm the element of the sequence used within the session ID and they will only answer if the element is invalid. An element sequence is invalid if it has been used in previous request in the answering server or if next elements of the sequence time out in the cache. Preventing memory linage is a simple a implementing an SQL server for each member farm to make this info persisted and have in memory only the most frequently used information. The devices of network used for communication between farm members must be all administrated by the owner of the application because the communication is insecure. With this structure scalability is assured.