Client Side Only Cookies

Question

I need something like a cookie, but I specifically don't want it going back to the server. I call it a "client side session cookie" but any reasonable mechanism would be great.

Basically, I want to store some data encrypted on the server, and have the user type a password into the browser. The browser decrypts the data with the password (or creates and encrypts the data with the password) and the server stores only encrypted data. To keep the data secure on the server, the server should not store and should never receive the password. Ideally there should be a cookie session expiration to clean up.

Of course I need it be available on multiple pages as the user walks through the web site.

The best I can come up with is some sort of iframe mechanism to store the data in javascript variables, but that is ugly. Does anyone have any ideas how to implement something like this?

FWIW, the platform is ASP.NET, but I don't suppose that matters. It needs to support a broad range of browsers, including mobile.

In response to one answer below, let me clarify. My question is not how to achieve the crypto, that isn't a problem. The question is where to store the password so that it is persistent from page to page, but not beyond a session, and in such a way that the server doesn't see it.

Answer 1

You could use JavaScript's localStorage object. The Dive Into HTML5 ebook has an excellent chapter on it. I think the chapter also mentions some possible work-arounds for browsers which to don't support localStorage.

Answer 2

For what you are looking for I would say that javascript is the best you could do.

You can retrieve the encrypted data onto the server and decrypt it using javascript on the client side. No transmission of password, no secret for the user.

It depends which encryption algorithm you are using but there is libraries for that (for example Stanford Javascript Crypto Library)

(but I don't understand why are you talking about cookies)

If you are interested in the storage aspect rather than the cryptography aspect, perhaps you might consider Thomas Frank's session variables