Session keys

UNICOM Intelligence Interviewer - Server Admin session management is based on Microsoft.Net FormsAuthentication.

When a user has authenticated with the server, UNICOM Intelligence Interviewer - Server Admin issues a random 120-bit ticket for that session. The ticket is randomized using the default Crypto Service Provider on the server and is stored in the UserTickets table of the mrUserData database. The session ticket is then encrypted and stored with the name of the server in a cookie. The encryption of the ticket is controlled by the server's .Net configuration.

UNICOM Intelligence Interviewer - Server Admin activities generate their own random session keys that are used to locate the session state for specific activities. These keys are randomly generated 120-bit values, randomized using the default Crypto Service Provider on the server. They are base64 encoded and stored in form post information.

Once a user has been authenticated and has an activity running, each transaction between the client and the server is probed for a valid authentication session, using the first session key. The state of the user's session is then located by using a string look-up using the second session key.

Each interview has a unique session key (session token). This is an encoded 160-bit key. The first 128 bits of the key are based on the CoCreateGuid function, which MSDN describes as follows:

"The CoCreateGuid function calls the RPC function UuidCreate, which creates a GUID, a globally unique 128-bit integer. Use the CoCreateGuid function when you need an absolutely unique number that you will use as a persistent identifier in a distributed environment. To a very high degree of certainty, this function returns a unique value — no other invocation, om the same or any other system (networked or not), should return the same value.

For security reasons, it is often desirable to keep ethernet/token ring addresses on networks from becoming available outside a company or organization. In Windows XP/2000, the UuidCreate function generates a UUID that cannot be traced to the ethernet/token ring address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer."

The last 32 bits are based on a random seeded run number. The encoding scheme is base32 as the session keys must be case insensitive.