views:

98

answers:

6

I want to send some data to a user after they log in to a web site, some kind of secret string for encryption.

I want to allow them to navigate around the web site, and I want to be able to use javascript on their machine to encrypt data before it's sent back to the server. Note: This will be in addition to using SSL.

I don't want to use cookies for this because they are sent to the server on each request.

So my aim is to have some data that will be sent across the wire only once for the whole session, but that when the user visits multiple pages, javascript will be able to access this secret. To be clear I never want to see the user's decrypted data, nor be able to.

Is this possible, maybe using HTML5 persistence or something? I need a cross-browser compatible solution please that will ideally work with IE6 (so that might shoot down any HTML5 magic).

Thanks

+2  A: 

If you are worried about snooping, use HTTPS. It sounds like a pretty fragile encryption mechanism though, why not go more 'traditional'?

Rushyo
This will be in addition to HTTPS. I never want to receive the unencrypted data.
Roger
+2  A: 

I'd doubt you can do this. A session is normally tied to a cookie (ie jsessionid), so to tie it to the "session" (ie you said "some data that will be sent across the wire only once for the whole session"), and have it available to the user, you need to put it in a cookie.

mlathe
No, if I put the key in a cookie, it'll be sent to the server on each request. I don't want that.
Roger
Lets say you secret string called S. If you expect the client computer to somehow get the "S", your server is going to have to at some time know what "S" is and send it to him. So it's not like you are making things more secure by not having the cookie sent over the wire each time. Just do what Rushyo said: use https, and secure your box.
mlathe
the string could probably be generated on the client machine, so i wouldn't ever see it. i'd hash the user's password with something else 'S', only I don't want to keep prompting for their password if they go to a different page.
Roger
This is an ugly hack, but i would look into how cookies that are made in Javascript are treated. When you create a cookie there is an implicit domain attached to it. I would GUESS that it uses the domain of where the JavaScript came from. If you load the JS from HostA, on a page from HostB, then i THINK that the cookie will only be sent to HostA. But that being said, i'd take a step back and really think about whether this patch makes sense. It seems goofy.
mlathe
I read your comment above more carefully, and it makes me wonder how after you encrypt the data using a hash you don't know anything about (like hash(password + timestamp)), you expect to use that data? how will you decrypt it?
mlathe
only the user will be able to decrypt it.
Roger
I don't really think putting the js on a different host will help. i'm thinking more along the lines of HTML5 persistence, but don't know much about it.
Roger
A: 

You could use a RIA plug-in like Flash or Silverlight. Both have mechanisms for storing data locally w/o sending it back to the server on each request. Java might as well.

Jesse Collins
Yeah, Flash would work for that. But unfortunately the site must be accessible from iphones, etc, and Jobs hates Flash
Roger
A: 

How about keeping the user on the secure page and sending the encrypted data back with ajax calls?

I also remember seeing a php script that would load a given page into an iframe based on some criteria. I think the example I saw was just a demo, where you selected a page from a select form. The page containing the iframe can be used to persist data.

jason
hmm, iframes... that could have potential
Roger
A: 

I think i'll take inspiration from the banking world and perform all of the encryption on the server. I can think of a way that I could generate a private key from the user's password making it impossible for me to decrypt data without the user being logged in.

I don't think there's a robust solution to my initial question, but thanks for the responses.

Roger
A: 

You can use localStorage on HTML5-supporting browsers (IE8, FF3+, Chrome, Safari 4+, Opera 9+). You can fall back to userData for IE6 and IE7. That gives you a guaranteed minimum of 64 KB of data on all platforms (minimum userData size).

There's a library that encapsulates the various strategies for storing data locally: PersistJS

I use this to store client-side state that doesn't need to be sent to the server with every request (e.g. resizable panel dimensions). I don't think it could offer any additional security though, because any attacker that can decrypt the SSL stream can get at your data, because they can observe all your javascript code.

Joeri Sebrechts
persistJS looks awesome. this is just what i was looking for. thanks a lot.
Roger