When should I invalidate a cache of a user's credentials?

Question

We develop a Windows client application that locally caches a user's credentials for connecting to our server application using the Windows Credential Management API.

Our caching logic works in the following way:

1. The user opens the application and selects a server in the UI. It then queries the server for authentication requirements. (If no credentials are needed, then we just connect without authentication.)
2. The application reads the cache to see if there are cached credentials.
3. If there are existing cached credentials, they are used. Otherwise, the Windows API is used to bring up a dialog box.
4. The application attempts to authenticate with the server using the credentials.
5. If the connection is a success, then the credentials used are cached for the lifetime of the Windows session (this is a feature of the Windows API). Otherwise, we clear the cache and return to step 3.

The question is: are there other valid situations where the credential cache should be cleared? In other words, what would you consider to be best practices on how to manage the lifetime and invalidation logic for this potentially sensitive information?

(Since I will probably be asked, the information we store using this API is encrypted using our own encryption logic, and stored in memory via SecureString. No doubt there are potential holes in this approach, but that is for another discussion.)

Answer 1

It depends on the security sensitivity of the application, and the environment in which it is used.

If this application is used by a business whose employees log off their machines at the end of their shifts, it is probably ok to keep the credentials cached for the Windows session. If they leave their computers logged in and unattended, then someone else with physical access could hijack their session.

An alternative is to cache the credentials (or a session token) for the session of the client application (or until the user tells it to log off). This allows the user to end just that session when they are done, which would be good for a more sensitive application. An inactivity timeout could also trigger a log off.

In evaluating what approach is appropiate for a givin situation, I would use a strict approach (less credential caching) as a starting point, and see if there is a case that more caching wouldn't cause a problem.