I have recently implemented a 'secure cookie' mechanism for storing a username and password as a temporary fix for a system that sits behind commercial single signon software. The problem being that the system that I was working with was not SSO compatible and needed a username and password.

The workaround uses Blowfish to encrypt the username and password with some salt along with an Md5 signature. This level of encryption was deemed to be adequate since it would take some serious computing resources to crack the data and it would be significantly easier to use social engineering to get the credentials.

I created a cookie granting application complete with login screen installed as a seperate app on an SSL secured machine. This solves the problem of how to get the users to create the cookie in the first place without passing unencrypted credentials over the network.

The user needs a valid SSO session before any resources are served. This stops the cookie from being hijacked since the user name in the cookie are compared to the SSO username. The credentials contained in the cookie are also validated against an LDAP directory each time the user logs in and a new persistent cookie set.

The key to the whole of this mechanism is the SSO software which does a proper job of protecteing the content but still requires the users to log on to an SSL protected form with a username and password.

This probably doesn't help you out a great deal in terms of a practical answer but the mechanism is reasonable and could be worth copying.

inman