TABLE OF CONTENTS Here are the steps that allow a real secure session to be used:
Establish the connection.
Negotiate the cryptographic session key.
Set up server-side state information for storage of session data.
Record all protocol specification information about the client connecting to the server such as IP address and so forth. This sets up the ICR data for impersonation detection while sessions are active in token-specific environments.
Server initiates secure communication.
Server must create session key.
Validation of client program version and so forth should all be done inside a cryptographic tunnel unless version stops secure communication from happening, which should result in the server ignoring and disconnecting the client.
Authenticate the user over the cryptographic tunnel. Use a challenge response mechanism. The client must identify itself as a user so the server knows which user this is and then it can verify that the password is valid. The client should not send the username in plaintext, but rather hash the username. The server as well should look up the username to determine which password is valid by having the username already stored in the table in hashed form.
Reauthenticate the user on a timely basis. It doesn't take more than a couple of seconds to retype a password and renegotiate a new session key. Albeit an interruption, doing so once an hour isn't so terrible and helps keep those nice session keys changing. Remember that sniffed traffic can be decrypted later.
Authentication...
